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Preface 


Many computer users are content to program in BASIC for all of 
their computing lives. A large number of others are eager to find out 
more about computing and their computer than the use of BASIC 
can lead to. Few, however, make much progress towards the use of 
machine code, which allows so much more control over the 
computer. The reason for this, to my mind, is that so many books 
which deal with machine code programming seem to start with the 
assumption that the reader is already familiar with the ideas and the 
words of this type of programming. Furthermore, many of these 
books treat machine code programming as a study in itself, leaving 
the reader with little clue as to how to apply machine code to his or 
her computer. An additional problem is that so many books on 
machine code programming emphasise mathematical program- 
ming, despite the fact that this is the least likely application that the 
user will consider. 

This book has two main aims. One is to introduce Oric-! and 
Oric Atmos owners to some of the details of how their 
microcomputers work, so leading to more effective programming 
even without delving into machine code. The second aim is to 
introduce the methods of machine code programming in a simple 
way. I must emphasise the word ‘introduce’. No single book can tell 
you all about machine code, even the machine code for one 
computer. All I can claim is that I can get you started. Getting 
started means that you will be able to write short machine code 
routines, understand machine code routines that you see printed in 
magazines, and gencrally make more effective use of your Oric-I or 
Oric Atmos. It also means that you will be able to make use of the 
many more advanced books on the subject, and progress to greater 
mastery of this fascinating topic. 

Throughout the book, you will see references to the ‘Oric/ Atmos’. 
The machine code that is used is identical for both computers, and 
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you will have to learn the same techniques whether you use the 
Oric-! or the newer Atmos. The programs in this book have all been 
written for and tested on a 48K Atmos, however. Insome examples, 
changes to address numbers will be needed to allow these programs 
to run on the Oric-1, but these are pointed out in the text. In Chapter 
8, the version of Oricmon that has been used as an example was the 
version for the Oric-1. Though this would not run on the Atmos, the 
commands are identical to those that will be used on the Atmos 
version when it is available. Atmos owners should note carefully 
that many items of machine code software which are advertised for 
the Oric-1 will not run correctly on the Atmos without changes. 

Understanding the operating system of your Oric/ Atmos, and 
having the ability to work in machine code can open up an entirely 
new world of computing to you. This is why you find that most of the 
really spectacular games are written in machine code, and you will 
also find that many programs which are written mainly in BASIC 
will incorporate pieces of machine code in order to make use of its 
greater speed and better control of the computer. 

I am very grateful to several people who made the production of 
this book possible. Of these, Richard Miles of Granada Publishing 
commissioned the book, and obtained an Atmos 48K for me. He, 
Sue Moore and Prue Harrison then did their usual miracles of 
meticulous effort on my manuscript. | am most grateful to Oric 
International for the loan of a48K Atmos, a machine which I greatly 
liked. I sincerely hope that this book will open up the horizons of 
many Oric/Atmos owners to what their machines can do once they 
have broken out of the restraints of BASIC. 

lan Sinclair 


Chapter One 
ROM, RAM, BytesandBits 


One of the things that discourage computer users from attempting to 
go beyond BASIC is the number of new words that spring up. The 
writers of many computing books, especially machine code 
computing, seem to assume that the reader has an electronics 
background and will understand all of the terms. I shall assume that 
you have no such background. All I shall assume is that you possess 
an Oric-1 or Atmos, and that you have some experience in 
programming your Oric or Atmos in BASIC. This means that we 
start at the correct place, which is the beginning. I don’t want in this 
book to have to interrupt important explanations with technical or 
mathematical details, and these will be found in the Appendices. This 
way, you can read the full explanation of some points if you feel 
inclined. or skip them if you do not. 

To start with, we have to think about »emory. A unit of memory 
for a computer is, as far as we are concerned, just an electrical circuit 
that acts like a switch. You walk into a room, switch a light on, and 
you never think that it’s remarkable in any way that the light stays on 
until you switch it off. You don’t go about telling your friends that 
the light circuit contains a memory ~ and yet each memory unit ofa 
computer is just a kind of miniature switch that can be turned on or 
off. What makes it a memory is that it will stay the way it has been 
turned, on or off, until it is changed. One unit of computer memory 
like thts is called a bit — the name being short for binary digis. 
meaning a unit that can be switched to either one of two possible 
ways. 

We'll stick with the idea of a switch, because it’s very useful. 
Suppose that we wanted to signal with electrical circuits and 
switches. We could use a circuit like the one in Fig. |.1. When the 
switch is on, the light is on, and we might take this as meaning YES. 
When the switch is turned off, the light goes out, and we might take 
this as meaning NO. You could attach any two meanings that you 
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s al common 
4—cable—»> 
current 
switch light return 
(transmitter) (receiver) (earth) 


Fig. 1.1. A single-line switch and bulb signalling system. 


liked to these two conditions (called ‘states’) of the light, so long as 
there are only two. Things improve if you can use two switches and 
two lights, as in Fig. 1.2. Now four different combinations are 
possible: (a) both off, (b) A on, B off, (c) A off, B on, (d) both on. 


4 A 
Se 
+ 
B B 
oo 





Fig. 1.2. Two-line signalling. Four possible signals can be sent. 


This set of four possibilities means that we could signal four 
different meanings. Using one line allows two possible codes; using 
two lines allows four codes. If you feel inclined to work them all out, 
you'll find that using three lines will allow eight different codes. A 
moment’s thought suggests that since 4 is 2X2, and eight is 2X2X2, 
then four lines might allow 2X2X2X2, which is 16, codes. It’s true, 
and since we usually write 2X2X2X2 as 24 (two to the power 4), we 
can find out how many codes could be transmitted by any number of 
lines. We would expect eight lines, forexample, to be able to carry 2 
codes, which is 256. A set of eight switches, then, could be arranged 
so as to convey 256 different meanings. It’s up to us to decide how we 
might want to use these signals. 

One particularly useful way is called binary code. Binary code isa 
way of writing numbers using only two digits, @ and 1. We can think 


ROM, RAM, Bytes and Bits 3 


of @ as meaning ‘switch off’ and | as meaning ‘switch on’. 256 
different numbers could be signalled, using eight switches, by 
thinking of @ as meaning off and | as meaning on. This group of 
eight is called a bye, and it’s the quantity that we use to specify the 
memory size of our computers. This is why the numbers 8 and 256 
occur so much in machine code computing. 

The way that the individual bits in a byte are arranged so as to 
indicate a number follows the same method that we use to indicate a 
number normally. When you write a number such as 256, the 6 
means six units, the 5 is written to the immediate left of the 6 and 
means five tens, and the 2 is written one more place to the left and 
means two hundreds. These positions indicate the importance or 
significance of a digit, as Fig. 1.3 shows. The 6 in 256 is called the 
‘least significant digit’, and the 2 is the ‘most significant digit’. 
Change the 6 to 7 or 5,and the change is just one part in 256. Change 
the 2 to | or 3 and the change is one hundred parts in 256 - much 
more important. 


? 5 3 a denary (decimal) number 
most significant least significant 
digit digit 


I @ | a binary number 


Fig. 1.3. The significance of digits. Our numbering system uses the position of 
a digit in a number to indicate its significance or importance. 


Having looked at bits and bytes, it’s time to go back to the idea of 
memory as a set of switches. As it happens, we need two types of 
memory in a computer. One type must be permanent, like 
mechanical switches or fixed connections, because it has to be used 
for retaining the number-coded instructions that operate the 
computer. This is the type of memory that is called ROM, meaning 
read-only memory. This implies that you can find out and copy what 
is in the memory, but not delete it or change it. The ROM is the most 
important part of your computer, because it contains all the 
instructions that make the computer carry out the actions of 
BASIC. 

When you write a program for yourself, the computer stores it in 
the form of another set of number-coded instructions in a part of 
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memory that can be used over and over again. This is a different type 
of memory that can be ‘written’ as well as ‘read’, and if we were 
logical about it we would refer to it as RWM, meaning read-write 
memory. Unfortunately, we're not very logical, and we call it RAM 
(meaning random-access memory). This was a name that was used 
in the very early days of computing to distinguish this type of 
memory from one which operated in a different way. We're stuck 
with the name of RAM now and probably forever! 


The number code caper 


Now we can get back to the bytes. We saw earlier that a byte, which 
is a group of eight bits, can consist of any one of 256 different 
arrangements of these bits. The most useful arrangement, however, 
is one that we call binary code. These different arrangements of 
binary code represent numbers which we write in ordinary formas @ 
to 255 (not 1 to 256, because we need a code for zero). Each byte of 
the 37631 bytes of RAM that are available in the 48K Oric/ Atmoscan 
store a number which is in this range of () to 255. 
Numbers by themselves are not of much use, and we wouldn't find 
a computer particularly useful if it could deal only with numbers 
between @ and 255, so we make use of these numbers as codes. Each 
number code can, in fact, be used to mean several different things. If 
you have worked with ASCII codes in BASIC, you will know that 
each letter of the alphabet and each of the digits @ to 9, and each 
punctuation mark, is coded in ASCII as a number between 32 (the 
space) and 127 (the left-arrow). That selection leaves you with a 
large number of ASCII code numbers which can be used for other 
purposes such as graphics characters. The ASCII code is not the 
only one, however. The Oric/ Atmos uses its own coded meanings 
for numbers in this range of 9 to 255. For example, when you type 
the word PRINT ina program line, what is placed inthe memory of 
the Oric/Atmos (when you press ENTER) is not the sequence of 
ASCII codes for PRINT. This would be 80,82,73,78,84 - one byte 
for each letter. What is put into memory, in fact, is one byte, the 
binary form of the number 186. This single byte is called a ‘token’ 
and it can be used by the computer in two ways. One way is to locate 
the ASCII codes for the characters that make up the word PRINT. 
These are stored inthe ROM, sothat when you LIST a program you 
will see the word PRINT appear, not a character whose code is 186. 
The other, even more important, use of the ‘token’ is to locate a set of 
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instructions which are also held in the ROM in the form of number 
codes. These instructions will cause characters to be printed on the 
screen, and the numbers that make up these codes are what we call 
‘machine code’. They control directly what the ‘machine’ does. That 
direct control is our reason for wanting to use machine code. When 
we use BASIC, the only commands we can use are the ones for which 
‘tokens’ are provided. By using machine code, we can make up our 
own commands and do what we please. Incidentally, the fact that 
PRINT generates one ‘token’ is the reason why it is possible to use ? 
in place of PRINT. The Oric/ Atmos has been designed so that a ? 
which is not placed between quotes will also cause 186 to be put into 
memory. 


Do-it-yourself spot 


As an aid to digesting all that information, try a short program. This 
one, in Fig. 1.4, is designed to reveal the keywords that are stored in 
the ROM, and it makes use of the BASIC instruction word PEEK. 


1@ FORN=492386TO049825 

2@ L=PEEK (N) 

34 IF L>128THENPRINTCHRS (L—-128) 
4@ IF L<128THENPRINTCHRS (L) 5 

38 NEXT 


Fig. 1.4. A program that reveals the keywords of Oric/Atmos BASIC. 


PEEK has to be followed by a number or number variable within 
brackets, and it means ‘find what byte is stored at this address 
number’. All of the bytes of memory within your Oric/ Atmos are 
numbered from zero upwards, one number for each byte. Because 
this is so much like the numbering of houses in a road, we refer to 
these numbers as addresses. The action of PEEK is to find what 
number, which must be between @ and 255, is stored at each address. 
The Oric/Atmos automatically converts these numbers from the 
binary form in which they are stored into the ordinary decimal 
(more correctly, denary) numbers that we normally use. By using 
CHR$ in our program, we can print the character whose ASCII 
code is the number we have PEEKed at. The program uses the 
variable N as an address number, and then checks that PEEK(N) 
gives a number less than 128 - in other words a number which is an 
ASCII code. If it is, then the character is printed in line 40. 
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Now the reason that we have to check is that the last character in 
each set of words, or word, is coded ina different way. The number 
that we find for the last character has had 128 added to the ASCII 
code. For example, the first three address locations that the program 
PEEKs at contain the numbers 69, 78 and 196. The number 69 is the 
ASCII code for E, 78 is the code for N, and then 196-128 = 68, 
which is the ASCII code for D. This is where the word END is 
stored, then. The reason for treating the last letter so differently is to 
save memory! If a gap were left between words, this would bea byte 
of memory wasted. As it is, there is no waste, because the last letter 
of a group always has a code number that is greater than 128, so the 
computer can recognise it easily. We have followed the same scheme 
in the BASIC program of Fig. 1.4 by using line 30 to print the correct 
letter and to take a new line and print the address number. 


Oric/ Atmos cutaway 


Now take a look at a diagram of the Oric/ Atmos in Fig. 1.5. It’s 
quite a simple diagram because I’ve omitted all of the detail, but it’s 
enough to give us a Clue about what's going on inside. This is the type 
of diagram that we calla ‘block diagram’, because each unit is drawn 
as a block with no details about what may be inside. Block diagrams 
are like small-scale maps which show us the main routes between 
towns but don’t show side-roads or town streets. A block diagram is 
enough to show us the main paths for electrical signals in the 
computer. 







Serial 


&. Keyboard 


Disk drive 


Fig. 1.5. A block diagram of Oric/Atmos. The connections marked ‘Buses’ 


consist of a large number of connecting links which join all of the units of the 
system. 
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The names of two of the blocks should be familiar already, ROM 
and RAM, but the other two are not. The block that is marked MPU 
is a particularly important one. MPU means Microprocessor Unit — 
some block diagrams use the letters CPU (Central Processing Unit). 
The MPU is the main ‘doing’ unit in the system, and it is, in fact, one 
single unit. The MPU is a single plug-in chunk, one of these silicon 
chips that you read about, encased in a slab of black plastic and 
provided with 40 connecting pins that are arranged in two rows of 20 
(Fig. 1.6). There are several different types of MPU made by 
different manufacturers, and the one in your Oric/ Atmos is called 
6502 (or 6502A). The 6502A is a version of the 6502 which operates 
at a higher speed. 


plastic block 
enclosing circuit 





20 pins this side 


marking for 
pin number 1 


Fig. 1.6. The 6502 MPU. The actual working part is smaller than a fingernail, 
eis larger plastic case (52 mm by 14 mm wide) makes it easier to work 
wit 

What does the MPU do? The answer is practically everything, and 
yet the actions that the MPU can carry out are remarkably few and 
simple. The MPU can load a byte, meaning that a byte which is 
stored in the memory can be copied into another store in the MPU. 
The MPU can also store a byte, meaning that a copy of a byte that is 
stored in the MPU can be placed in any address in the memory. 
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These two actions (see Fig. 1.7.) are the ones that the MPU spends 
most of its working life in carrying out. By combining them, we can 
copy a byte from any address in memory to any other. You don’t 
think that’s very useful? That copying action is just what goes on 
when you press the letter H on the keyboard and see the H appear on 
the screen. The MPU treats the keyboard as one piece of memory 
and the screen as another, and copies bytes from one to the other as 
you type. That’s a considerable simplification, but it willdo for now 
just to show how important the action is. 


MPU LOAD 


ROM or RAM 


STORE 


ROM or RAM 


Fig. 1.7. Loading and storing. Loading means signalling to the MPU from the 
memory, so that the digits of a byte are copied into the MPU. Storing is the 
opposite process. 


Loading and storing are two very important actions of the MPU, 
but there are several others. One set of actions is the ‘arithmetic set’. 
For most types of MPU, these consist of addition and subtraction 
only, using only single-byte numbers. Since a single-byte number 
means a number between @ and 255, how does the computer manage 
to carry out actions like multiplication of large numbers, division, 
raising to powers, logarithms, sines, and all the rest? The answer is 
by machine code programs that are stored in the ROM. If these 
programs were not there you would have to write your own. There 
aren’t many computer users who would like to set about that task. 
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There’s also the logic set. MPU logic is, like all MPU actions, 
simple and subject to rigorous rules. Logic actions compare the bits of 
two bytes and produce an ‘answer’ which depends on the bit values 
that are being compared and on the logic rule that is being followed. 
The three main logic rules are called AND, OR and XOR, and Fig. 
1.8 shows how they are applied. 

AND 
The result of AN Ding two bits will be | if both bits are 1, but 9 otherwise: 
| AND @=9@ 
§ ANDI=9 
For two bytes, corresponding bits are ANDed: 

IOTIOIII 

AND = 9POOITII 
GONOITI 
only these bits 
exist in both bytes. 





1ANDI=1 9 ANDO=9 








OR 
rhe result of ORing two bits will be | if either or both bits are 1, but @ 
otherwise: 


LOR(=1 
LORI=1 9ORO=0 
9ORI=1 


For two bytes, corresponding bits are ORed: 


IO1IM 111 
OR OOOOITII 
TC 
I 
only bit which 
is 9 in both. 


XOR (Exclusive OR) 

Like OR, but result is zero if the bits are identical: 

1XORQ= 1 

0 XOR I= 1 
IPIIOIII 


XOR  OOPOIITI 
TPTII90O 


——— ee 


1XOR1=90 | 0 XORO=90 


if two bits are identical 
the result is zero. 
Fig. 7.8. The rules for the three logic actions, AND, OR and XOR. 
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Another set of actions is called the ‘jump set’. A jump means a 
change of address, rather like the action of GOTO in BASIC. A 
combination of a test and a jump is the way that the MPU carries out 
its decision steps. Just as you can program in BASIC: 


IF A = 36 THEN GOTO 1656 


so the MPU can be made to carry out an instruction which is at an 
entirely different address from the normal next address. The MPU is 
a programmed device, meaning that it carries out each of its actions 
as a result of being fed with an instruction byte which has been 
stored in the memory. Normally when the MPU is fed with an 
instruction from an address somewhere (usually in ROM), it carries 
out the instruction and then reads the instruction byte that is stored 
in the next address up. A jump instruction would prevent this from 
happening and would, instead, cause the MPU to read from another 
address - the one that was specified in the jump instruction. This 
jump action can be made to depend on the result of a test. The test 
will usually be carried out on the result of the previous action 

whether it gave a zero, positive or negative result, for example. 

That isn’t a very long or exciting list, but the actions that I’ve 
omitted are either unimportant at this stage, or not particularly 
different from the ones in the list. What 1 want to emphasise is that 
the magical microprocessor isn’t such a very smart device. What 
makes it so vital to the computer is that it can be programmed and 
that it can carry out its actions very quickly. Equally important Is the 
fact that the microprocessor can be programmed by sending it 
electrical signals. 

These signals are sent to eight pins, called the ‘data pins’, of the 
MPU. It doesn’t take much of a guess to realise that these eight pins 
correspond to the eight bits of a byte. Each byte of the memory can 
therefore affect the MPU by sharing its electrical signals with the 
MPU. Since this is a long-winded description of the process, we call 
it ‘reading’. Reading means that a byte of memory is connected 
along eight lines tothe MPU, so that each I bit will cause a | signal 
on a data pin, and each @ bit will cause a () signal on a data pin. Just 
as reading a paper or listening to a recording does not destroy what 
is written or recorded, reading a memory does not change the 
memory in any way, and nothing is taken out. The opposite process 
of writing does, however, change the memory. Like recording a tape, 
writing wipes out whatever existed there before. When the MPU 
writes a byte to an address in the memory, whatever was formerly 
stored at that address is no longer there — it has been replaced by the 
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new byte. This is why it is so easy to write new BASIC lines replacing 
old ones at the same line number. 


Table d’H6te? 


Do you really write programs in BASIC? It might sound like a silly 
question, but it’s a serious one. The actual work of a program is done 
by coded instructions to the MPU, and if you write only in BASIC, 
you don’t write these. All that you do is to select from a menu of 
choices that we call the BASIC keywords, and arrange them in the 
order that you hope will produce the correct results. Your choice is 
limited to the keywords that are designed into the ROM. We can’t 
alter the ROM, and if we want to carry out an action that is not 
provided for by a keyword, we must either combine a number of 
keywords (a BASIC program) or operate directly on the MPU with 
number codes (machine code). When you have to carry out actions 
by combining a number of BASIC commands, the result is clumsy, 
especially if each command is a collection of other commands. 
Direct action is quick, but it can be difficult. The direct action that I 
am talking about is machine code, and a lot of this book will be 
devoted to understanding this ‘language’ which is difficult just 
because it’s simple! 

Take a situation which will illustrate this paradox. Suppose you 
want a wall built. You could ask a builder. Just tell him that you 
want a wall built across the back garden, and then sit back and wait. 
This is like using BASIC with a command word for ‘build a wall’. 
There’s a lot of work to be done, but you don’t have to bother about 
the details. 

Now think of another possibility. Suppose you had a robot which 
could carry out instructions mindlessly but incredibly quickly. You 
couldn’t tell it to ‘build a wall’ because these instructions are beyond 
its understanding. You have to tell it in detail, such as: ‘stretch a line 
from a point 85 feet from the kitchen edge of the house, measured 
along the fence southwards, toa point 87 feet from the lounge end of 
the house measured along that fence southwards. Dig a trench 
eighteen inches deep and one foot wide along the path of your line. 
Mix three bags of sand and two of cement with four barrow-loads of 
pebbles for three minutes. Mix water into this until a pail filled with 
the mixture will take ten seconds to empty when held upside down. 
Fill the trench with the niixture ...°. The instructions are very 
detailed — they have to be for a brainless robot — but they will be 
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carried out flawlessly and quickly. If you've forgotten anything, no 
matter how obvious, it won’t be done. Forget to specify how much 
mortar, what mixture and where to place it, and your bricks will be 
put up without mortar. Forget to specify the height of the wall, and 
the robot will keep piling one layer on top of another, like the 
Sorcerer's Apprentice, until someone sneezes and the whole wall 
falls down. 

The parallel with programming is remarkably close. One keyword 
in BASIC is like the ‘build a wall’ instruction to the builder. It will 
cause a lot of work to be done, drawing ona lot of instructions that 
are not yours ~ but it may not be done as fast as you like. If you can 
be bothered with specifying the detail, machine code is a lot faster 
because you are giving your instructions direct to an incredibly fast 
but mindless machine, the microprocessor. We can stretch the 
similarity further. If you said to your builder ‘mend the car’, he 
might be unwilling or unable to do so. The correct set of detailed 
instructions to the robot would, however, get this job done. Machine 
code can be used to make your computer carry out actions that are 
simply not provided for in BASIC, though it’s fair to say that many 
modern computers allow a much greater range of commands than 
early models, and this aspect of machine code is not quite so 
important as it used to be. 

One last look at the block diagram is needed before we start on the 
inner workings of the Oric/ Atmos. The block which is marked ‘Port’ 
includes more than one chip. A por: in computing language means 
something that is used to pass information, one byte at a time, into 
or out from the rest of the system —- the MPU, ROM and RAM. The 
reason for having a separate section to handle this is that inputs and 
outputs are important but slow actions. By using a port we can let 
the microprocessor choose when it wants to read an input or write an 
output. In addition, we can isolate inputs and outputs from the 
normal action of the MPU. This is why nothing appears on the 
screen in a BASIC program except where we have a PRINT 
command in the program. It's also why pressing the PLAY key of 
the cassette recorder has no effect until you type CLOAD (witha 
filename) and press ENTER. The port keeps the action of the 
computer hidden from you until you actually need to have an input 
or an output. 

We have now looked at all of the important sections of your 
Oric/ Atmos. I’ve used some terms loosely — purists will object to the 
way I’ve used the word ‘port’, for example - but no-one can quarrel 
with the actions that are carried out. What we have to do now is to 
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look at how the computer is organised to make use of the MPU, 
ROM, RAM and ports so that it can be programmed in BASIC and 
can runa BASIC program. It looks like a good place to start another 
chapter! 


Chapter Two 
Digging Inside the 
Oric/Atmos 


I don’t mean digging inside literally - you don’t have to open up the 
case. What I do mean is that we are going to look at how the Oric-| 
and Atmos are designed to load and run BASIC programs. We'll 
start with a simplified version of the action of the whole system, 
omitting details for the moment. 

The ROM of your Oric/ Atmos, which starts at address 49152, 
consists of a large number of short programs - subroutines —~ which 
are written in machine code, along with sets of values (tables) like the 
table of keywords. The ROM of the Atmos is similar to that of the 
Oric-1, but there are several important differences. There will be at 
least one machine code subroutine for each keyword in BASIC, and 
some of the keywords may require the use of many subroutines. 
When you switch on your Oric/ Atmos, the piece of machine code 
that is carried out first is called the ‘initialisation routine’. This is a 
long piece of program, but because machine code is fast, carrying 
out instructions at the rate of many thousands per second, you see 
very little evidence of all this activity. All that you notice is the bars 
on the screen in the time between switching on and seeing the Oric 
copyright notice. In this brief time, though, the action of the RAM 
part of the memory has been checked, some of the RAM has been 
‘written’ with bytes that will be used later, and most of the RAM has 
been cleared for use. ‘Cleared for use’ does not mean that nothing is 
stored in the RAM. When you switch off the computer, the RAM 
loses all trace of stored signals, but when you switch on again the 
memory cells don’t remain storing zeros. In each byte, some of the 
bits will switch to | and some will switch to # when power is applied. 
This happens quite at random, so that if you could examine what 
was stored in each byte just after switching on, you would find a set of 
meaningless numbers. These would consist of numbers in the range 
§ to 255, the normal range of numbers for a byte of memory. These 
numbers are ‘garbage’ - they weren't put into memory deliberately, 
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nor do they form useful instructions or data. The first job of the 
computer, then, is to clean up. In place of the random numbers, the 
computer substitutes a very much more ordered pattern of bytes of 
number 85. Try this — switch on, and type (no line number): 


FOR N=1289 TO 1489:?PEEK(N);* ";;:NEXT 


and then press RETURN. The range of memory addresses we have 
used is the ‘start of BASIC’ range, where the first bytes of a BASIC 
program are normally stored. If we have just switched on, and 
haven't used a line number for the command, there will be nothing 
stored here except for the pattern that was left after the initialisation 
and as a result of the command. As you'll see on the screen, the 
pattern consists mainly of the chain of 85s. At the start, though, you 
will find other numbers. The numbers at the start are placed there by 
the FOR N = 1280 ... command that you used to discover the 
pattern, and the other numbers are put there by the action of this 
command as it is executed. Why 85? Well, in binary, 85is 91919101, 
and it’s a good pattern to use to check if the memory is working 
correctly. 

The initialising program has a lot more to do. The first section of 
RAM, from address @ to 1279, is for ‘system use’. This is because the 
machine code subroutines which carry out the actions of BASIC 
need to store quantities in memory as they are working. Address 
numbers 154 and 155, for example, hold the address of the first byte 
of a BASIC program. A much larger section of the memory is used 
for storing numbers that make text and graphics appear on the 
screen. In addition, some RAM has also to be used to hold 
quantities that are created when a program runs That’s what we are 
going to look at now. 


Variables on the table 


BASIC programs make a lot of use of variables, meaning the use of 
letters to represent numbers and words. Each time you ‘declare a 
variable’ by using a line like: 

N = 20 or AS = “SMITH” 
the computer has to take up memory space with the name (N or AS 
or whatever you have used) and the value (like 20 or SMITH) that 


you have assigned to it. The piece of memory that is used to keep 
track of variables is called the variable list table (VLT). It doesn’t 


16 Oric and Atmos Machine Code 


occupy any fixed place in the memory, but is stored in the free space 
just above your program. If youadd one more line to your program, 
the VLT address has to be moved to a set of higher address numbers. 
If you delete a line from your program, the VLT will be moved down 
in the same way so that it is always kept just following the last line of 
BASIC. 

Now because the variable list table address can and does move 
around as the program is altered, the computer must at all times 
keep a note of where the table starts. This is done by using two bytes 
of a piece of memory that is reserved for system use, the addresses 
156 and 157. You may wonder why two addresses are used. The 
reason is that one byte can hold a number only up to 25S in value. If 
we use two bytes however, we can hold the number of 256’s in one 
byte and the remainder in the other. A number like 257, for example, 
is one 256 and one remaining. We could code this as I,!. This means 
that a | is stored in the byte that is reserved for 256's, and | in the 
byte reserved for units. The order of storing the numbers is low-byte 
then high-byte. To find the number that is stored, we multiply the 
second byte by 256 and add the first byte. Forexample, if you found 
3.8 stored in two consecutive addresses that were used in this way, 
this would mean the number: 


8*256 + 3 = 2051 


The biggest number that we can store using two bytes like this is 
255,255, which means 255*256 + 255 = 65535. This is the reason 
that you can’t use very large numbers like 70000 as line numbers in 
the Oric/ Atmos - the operating system uses only two bytes to store 
its line numbers. In fact, for other reasons, the maximum number 
that you can use is 63999. 

All of this means that we can find the address that is stored in 
addresses 156 and 157 by using the formula: 


”?PEEK(156)+256* PEEK(157) 


If you use this just after you have switched on your Oric/ Atmos, 
then the result on the Oric/ Atmos is the address number 1283. This 
is just above the address at which the first byte of a BASIC program 
would be stored. To see this in action, type the line: 


19 N= 20 
and try 7?PEEK(156)+256* PEEK(157) again. If you typed this line 


as I did, with a space between the line number and the ‘N’, then the 
address that you get is 1292. The variable list table has moved 
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upwards in the memory, by 9 bytes. That’s more than the number of 
bytes that you typed, you'll notice reasons later. 

Quite a lot of important addresses that the computer uses are 
‘dynamically allocated’ like this. ‘Dynamically allocated’ means that 
the computer will change the place where groups of bytes are to be 
kept. It will then keep track of where they have been stored by 
altering an address that Is held ina pair of bytes such as this example. 
This has important implications for how you use your computer. 
For example, if you shift the VLT by poking new numbers into 
addresses 156 and 157, the computer can’t find its variable values. 
Try this — after finding the VLT address, but without running the 
one-line program, 19 N = 20 - type ?N. The answer will be zero. 
Why? Because the program has not been run. The address 1292 is 
where the VLT will start, but there’s no VLT created until the 
program runs. This makes it easy for you to add or delete lines at this 
stage. All that will have to be altered is the pair of numbers in 
addresses 156 and 157. The VLT values are put in place only when 
the program runs, and a new table is created all over again each time 
you type RUN and press RETURN. Each time a new table is 
created, a new pair of bytes will be put into 156 and 157. That’s why 
you can’t resume a program after editing — you have to RUN again 
to create a new VLT at a new address. If you RUN the one-line 
program now, and then type ?N you will get the expected answer of 
2. Now type (no line number) POKE 157,6, and press RETURN. 
This has changed the address of the VLT to an address where there is 
no VLT. Try ?N and see what you get. On my machine, it was zero, 
because the correct value of variable N can be found no longer. If 
your Oric/ Atmos locks up during this exercise, then you may have 
to switch off to regain control. This seldom happens but if you do 
have to switch off, the program will be lost. Note, incidentally, the 
use of POKE to place a new value into a memory address. The 
correct form of the command is POKE A,D. A is an address, and 
will be in the range @ to 49151 (the range of values of RAM 
memory) for the 48K Oric/ Atmos. D is the data that you place into 
this memory address, and it must be a value between ( and 255. If 
you try to POKE a number greater than 255, you will get an 
‘ILLEGAL QUANTITY ERROR’ message instead. 


A look at the table 


It’s time now to do something more constructive, and take a look at 
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What is stored in the VLT. When we do these investigations, it’s 
important to ensure that the computer is clear of the results of 
previous work, so it’s advisable to switch off and then on again, 
before each effort. Simply pressing the RESTORE button under the 
computer does not alter values that you may have poked into the 
memory. It’s tedious. | know, but that’s machine code for you! 
To work, then. After switching off and on again, type the line 


I) N = 20 


again, and find the VLT address by using ?PEEK(156)+256* 
PEEK(157). This gave me the address 1292 again. Now type RUN, 
so that values are put intothe VLT, and take a look at what has been 
stored there. This is done by using the command: 


FOR X = 1292 TO 1300:?X;" "; PEEK(X):NEXT 


and pressing RETURN. This gives the listing that is illustrated in 
Fig. 2.1. Now can we recognise anything here? We ought to 
recognise the first byte of 78, because that’s the ASCII code for N! 
The next byte is zero because our variable is called N, not Nl or NG 
orany other two-letter name. If we used a two-letter name, then both 
addresses 1292 and 1293 would have been occupied. The next five 
bytes, then, must be the way that the number 2@ has been coded. 


1292 «78 
1295 4 
1294 135 
1295 «E2 
1296 a 
1297. @ 
1298 
1299 ge 
12a 


Fig. 2.1. The variable list table entry for a simple number variable. 


At this point, don’t worry about how these numbers are used to 
represent 20 - just accept that they do! How do | know that it’s the 
next five bytes that represent the number 29? Easy, the byte in 
address 1299 is 88, which is the ASCII for X, and that’s the variable 
that we used to print the table values! The Oric/ Atmos always uses 
Just five bytes for any value of number variable, no matter whether 
it’s a small number like 2, or a very much larger one like 
1427068315, or a fraction, or negative. This makes the storage of 
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number variables simple, and it also makes it easy for the computer 
to find variables. If, for example, it is looking for the value of a 
variable called Y, then when it finds ‘N’ (coded as ASCII 78) it need 
not waste time with the next six bytes (one fora second letter, five for 
the value), but move to the next place where a variable name will be 
stored. If you are curious, and have a head for mathematics, 
Appendix A shows what method of coding is used to convert 
numbers into five bytes. For the purposes of this book you don’t, 
however, need to understand how the coding is done as long as you 
know how the code is stored and how many bytes are needed. 


Tying up a string 


Now we need to take a look at howa string variable is stored. Switch 
off and on again, and then type the line: 


19 ABS = “THIS IS A STRING” 


RUN this one-liner, and then find the VLT address by using 
addresses 156 and 157 as before. I obtained 1319 for this address. 
Now use: 


FOR X = 1319 TO 1320:?X;“ ";PEEK(X):NEXT 


to find what is in the VLT. This time, it’s as Fig. 2.2 shows. The first 
value in this table is 65, which is the ASCII code for A. The second, 
however, is 194. Now this is the ASCII code for B with 128 added to 
it, and it’s the way that the Oric/ Atmos recognises that this is a string 
variable. If you had used the variable name A$ rather than AB$, 


1219 65 
isil 194 
{212 14 
1315 14 
1214 = 
13is a 
1216 Se 
1217 8a 
1218 a 
1319 139 
13529 a7 


Fig. 2.2. The VLT entry for a string variable. 
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then the second number (at address 1311) would have been 128, not 
9. When you use a number variable, the second ASCII code of the 
name will be 9, or one of the ASCII code numbers, never greater 
than 127. Good thinking, designers! 

Now take a look at the rest of the entry for this string. It doesn’t 
look much like the ASCII codes for the letters, does it? In fact, the 
entry consists of seven bytes only, just the same total length as a 
number variable. The clue to what is being done emerges when we 
take a look at the numbers. The number that follows the code for B 
(194, because 128 has been added to the ASCII code) is 16. Now I6is 
the number of characters in the string. If you count the number of 
letters and spaces you'll see that this is what it comes to. The next 
two bytes are 19 and 5. Now two bytes together are always likely to 
be an address, and if we combine them in the usual way, using 
5*256+10, we get 1290. The next step in the trail is to try 
PRINT PEEK(1290). Sure enough, it’s 84, which is the ASCII code 
for ‘T’. 1299, then, is the address of the first byte of the string. 

Let’s gather all this up. The Oric/ Atmos stores an entry of seven 
bytes in its VLT foreach string. Of these seven bytes, the first two are 

for the string name, and the second will be 128 or more. When a two- 
character name is used, 128 is added to the ASCII code for the 
second letter. This allows the computer to distinguish a string 
variable from a number variable. The next five bytes then contain 
the length of the string and the address in memory of its first byte. As 
it happens, only three bytes are needed to keep track of a string. One 
byte is needed for the length — no string will exceed 255 characters. 
Though you cannot enter a string of more than 8@ characters from 
the keyboard, you can join strings to make a length of up to 255 
characters. Two bytes are needed for the address, so that two of the 
seven bytes that are used in the string VLT entry are not needed 
except as separators. The convenience of having the same total 
length of VLT entry for a string as fora number outweighs the slight 
waste of the last two bytes in each string entry. 

In this example, the string is stored at an address lower than the 
VLT, in the ‘BASIC text’ part of the memory. This is the part of the 

memory which contains the program, and since the ASCII codes for 
the string are placed here when you type the program, it’s as good a 
resting place as any. Numbers must be transferred to the VLT 
because they are not stored as ASCII codes. The question now is, 
what happens when a string is created which does not exist in the 
program? Switch off, then on again, and type: 
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10 A$ = “AB”:B$ = “CD”:C$ = A$ + BS 


Now RUN this, and you will find that your VLT is longer, as you 
might expect. You will have to look at memory addresses from 1312 
to 1335 this time. You will find the entries for A$ and BS, just as you 
would expect, giving addresses inside the program memory region, 


izi2 65 
i A 128 
1214 2 
isa a rs 
Lobe pe 
isi? ES 
1218 2 
isi? 56 
L220 i235 
L321 2 
Lee we 
Les a 
1224 4 
12275 @ 
1224 &7 
a2? 128 
1328 4 
1329 aa Pa 
12.36 1S 
| “ 

5 fe 
Loss 8 
1224 Se 
L3c0 Loy 


Fig. 2.3. The VLT entry for a string which ts not stored in the program part of 
memory. 


as shown in Fig. 2.3. The variable C$, however, gives the bytes 
252.151 for its address. This corresponds to an address of 38998 (it’s 
151*256 + 252, remember) for this string. We can take a look at 
these addresses. If you type: 


FORX=38998TO38911:?X;" ";PEEK(X);* “;CHRS 
(PEEK(X)):NEXT 


then all will be revealed. The ASCII codes for letters ABCD are now 
stored here, and the use of CHR$ in the program reveals them. 
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Into integers 


We've looked at the storage of numbers and of strings, but we should 
not forget that the Oric/ Atmos allows two types of numbers to be 
stored. One of these number types is called ‘real’, and a variable fora 
real number uses a letter, or pair of letters, or letter and digit like A, 
AB or A2to represent it. A real number is coded in the way that we 
have already seen, using a total of seven bytes. Of these, two are for 
the name, and five for the value. A real number can be positive, 
negative, or fractional, and its range of size can be from about 1038 to 
10°“. The integer numbers are whole numbers, no fractions allowed, 
and can range from —32768 to +32767. It’s time to take a look at 
these numbers in the VLT. 

Start, as usual, by switching off and then on again to clear the 
memory. Now type the one-liner: 


1f A%=15:B%=300 


and RUN this. Find the position of the VLT as usual by peeking 
addresses 156 and 157. My Atmos came up with 1309. Now type: 


FOR X= 13909TOI318:PRINTX;* *;PEEK(X):NEXT 


and press RETURN. This will give you the sequence which is shown 
in Fig. 2.4. 


1S¢e@ 193 
Liza 128 
1342 ” 
1205 15 
12044 a 
1205 a 
1345 a 
1207 194 
1298 128 
1209 1 
1314 44 
1511 a 
1312 a 
1S13 a 
1214 22 
1215 a 
1316 139 
- 13517 3& 
1318 192 


Fig. 2.4. The VLT entry for two integer numbers. 
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It's not the same as the real number sequence that we saw in Fig. 
2.1. To start with, something has been done to the first byte, the one 
that should represent the variable name of A%. The byte is 193, 
which is just 65+ 128. It’s the code for A with 128 added. The second 
byte is 128. This suggests that when we create an integer variable 
name, the machine adds 128 to both of the letters of the name. Can 
you see the pattern in all this? For a real number, the letters of the 
name use ASCII codes. For a string, the second code for the name is 
128, or an ASCII code with 128 added. For an integer, 128 has been 
added to the first code as well. This is how the machine can 
distinguish between different letter variables. The signs % and $ are 
not stored in the memory! 

We need now to look at how the numbers are stored, though. The 
bytes that follow the two ‘variable name’ bytes are 9,15,9,0,0, and 
this seems to indicate that the number [5 has been stored unaltered. 
This is quite unlike the transformation that we saw carried out for 
the storage of a real number. The number 300, however, is stored as 
1.44. Now could this be a two-byte storage system? We can try it - 
256* | + 44 = 300. The number has been stored as two bytes, with 
the high byte first, unlike the order that is used for line numbers or 
memory address numbers. The VLT entry is still of seven bytes, with 
three of them unused this time. 

How does this explain the use of integers? Well, for one thing, we 
can explain the range of integer numbers. If we use only two bytes 
for storage, we can’t store a number greater than the one which uses 
255 stored in each byte. This number would be 255*256 + 255, which 
is 65536. Now we know that the range of integers is from —32768 to 
+ 32767 ~ and these numbers add up to 65535! Instead of making 
integer numbers cover just () to 65535, then, the Oric/ Atmos covers 
the more useful range of —32768 to +32767. The reasons for this 
range are illustrated in more detail in Appendix A. 

Using integers has several other side-effects. One is that integers 
are stored with perfect precision. When you declare A% = 17412, 
then that’s the number in the store, not 17411.9999999. A ‘real’ 
number is almost always an approximation, and when we use ‘real’ 
numbers. we have to be prepared for some ‘rounding’. You've 
probably met calculators that told you that the answer toa problem 
was 3.9999999 rather than 4.0. This is caused by these approxima- 
tions in storing real numbers, and some calculators would round the 
figure to 4 while others would not. If you work on the Oric/ Atmos 
using integers, these problems do not bother you. The other 
advantage of using integers is speed. Because an integer number is 
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stored in two bytes. the computer can deal with it much more 
quickly than with a ‘real’ number which requires five bytes, and 
which needs more elaborate decoding. If you want speed, then, use 
integers — but you probably knew that already! 


Program time 


It’s time now to look at how a program is stored in the memory of 
your Oric/ Atmos. As before, we shall rely on PEEKs at parts of the 
memory to find out what is happening. The first thing we need to 
know, however, is where the bytes that form the address of the start 
of a program are stored. As it happens, they are stored at 154 and 
155. 

We can therefore start looking at a program as it exists in the 
memory. Type the program as shown in Fig. 2.5, but don’t run it. 


1@ A=14 
22 PRINT A 
=@ C$="ATMCS" 


Fig. 2.5. A simple BASIC program. 


Now type: 
?PEEK(154)+256*PEEK(155) 


and you will find the address at which the first byte of this program 
starts. In this example, my Atmos gave the address 1281. Now when 
you use the usual loop to print values of the PEEK numbers from 
this address onwards, you get the list as shown in Fig. 2.6. At first 
sight it looks like a stream of meaningless numbers, but when you 
look more carefully, you can see some pattern in it. As usual, the 
ASCII codes act as useful signposts. Five places along, for example, 
you can see the number 65, which is the ASCII code for ‘A’. Since we 
know that the line is ‘A = 1’, we can look for the rest of this line. 


a 73 a 129 14 a 14 a 65 
212 49 48 a 18 a 204 a 

186 ae 635 

7 36 21 


a= >4 


Pw) 


= 3 
=4 635 84 77 7? 
G 5] 


oN 


Fig. 2.6. The bytes that represent the program in memory. 
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The 19 is recognisable as 49 (ASCII ‘I’) and 48 (ASCII ‘9’), so that 
the number 212 must represent the ‘=’ sign. Note that 212 is nor the 
ASCII code for ‘=’. Instead, it is one of those ‘tokens’ that I 
mentioned in Chapter 1. It’s a token because the computer is 
required to carry out an action, not just store an ASCII code here. 
The # that follows the 49 (ASCII ‘#’) marks the end of this line. 

Now we have to grapple with the first four bytes. The first two are, 
as you might suspect from looking at them, an address. The 19,5 
makes up the address 5*256 + 19, which is 1299. What is this 
address? Why, it’s the address of the first byte of the next line! This is 
how the operating system of the Oric/ Atmos can pick out lines, and 
put them into the correct sequence, no matter what order you use to 
enter them. The final mystery is easily solved. Looking at the third 
and fourth bytes of each of the lines shows the sequence 19, 20, 30 - 
the line numbers. There are two bytes reserved for the line numbers 
because we want to have line numbers higher than 255. For line 
numbers smaller than 256, the second of these bytes - the more 
significant byte - is not used. The last byte of each line is @. 

Now take a look at the other lines, as they appear stored in the 
memory. We have met the PRINT token of 186 before, and all the 
rest should be familiar by now. The only novelty is the end of the 
program. The last line ends with a @ as usual, but following it, in the 
place where the address bytes for the next line would be, is another 
pair of zeros. This is the marker that the computer uses for END. 

We can carry out some interesting changes on a program like this. 
Suppose, for example, that we poke the addresses that are used to 
carry the line numbers. If you type: 


POKE12929,19:POKE1399, 19 


and press RETURN, you will have placed the number 19 in each line 
number address for the lines 20 and 39. Now LIST and look at the 
result! It’s a program of line 19's. Contrary to what you might 
expect, this will RUN perfectly normally. The action of running, you 
see, depends on the ‘next line’ addresses being correct, not on how 
the lines are numbered. A program that has been altered inthis way, 
however, is certainly not normal. Try, for example, using the screen 
editing system to change the second line A to B, so that the line reads 
PRINT B. Now RUN and then LIST. You will find that the previous 
first line has disappeared, and the new first line is PRINT A, with 
PRINT B as the second line! You can, however, record a program 
which has been altered in this way, and replay it normally. This is the 
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erm of a method by which you can make a program difficult to 
alter. 


Running the program 


Now that we have looked at the way in which a program is coded and 
stored in the memory of the Oric/Atmos, we can give a bit of 
thought as to how it runs. This action is carried out by the most 
complicated part of the operating system, and it has to be givena 
starting address. This address comes, as you might expect, from the 
locations 154 and 155 which we have used. Suppose we go through 
the actions, omitting detail, of the three-line program of Fig. 2.5. At 
the first address in BASIC, the RUN subroutine will read the first 
two bytes, and store them temporarily. These bytes will be used in 
place of the ‘start of BASIC’ address when the next line is carried 
out. The line number bytes are then read and stored. Why? So that if 
there is a syntax error in the line, the computer will be able to print 
out the message: ‘SYNTAX ERROR IN 1@’ rather than ‘SYNTAX 
ERROR SOMEWHERE’! The next byte is an ASCII code, and the 
computer will take this as being a variable name. In the old days, the 
word LET had to be used to ‘declare a variable’. There was a token 
for LET, but in most types of modern machines, this token is not 
used. The difference is that a token is now put in automatically for 
the ‘=’ sign when a letter immediately follows a line number or a 
colon. If you do type LET, then the same token is used. 
Following the ASCII code for ‘A’, the special token for the ‘=’ 
sign then causes a subroutine to swing into action. This one creates 
an entry in the variable list table, at the first available address, and 
puts the ASCII code for A in that place. The next address inthe VLT 
is left blank — there’s no second letter for this variable name. The 
number 1 is then read and converted to the special binary form, as 
noted in Appendix A. This set of bytes is also placed in the VLT as 
the entry for A. The next byte of the program is then read - it’s 9, 
meaning end of line, so that the address for the next line, which was 
read as the first action, is now placed into the microprocessor. The 
type of action that we have considered in detail for line 19 then 
repeats with line 20. This time, more has to be done when the action 
token is read. Since this is the token for PRINT, the subroutine for 
PRINT must be called up. It will locate the address of the next 
vacant place on the screen. This is done by keeping a note of the 
address ina couple of bytes of RAM - read these bytes, and you have 
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the address. The value of A is then found in the VLT, and the bytes 
converted back to ASCII code form. The codes are then placed, one 
by one, in the screen memory. Doing this causes the characters to 
become visible on the screen, because of another subroutine. Once 
again, the zero at the end of the line causes the next line number to be 
used. At the end of the third line, however, the ‘next line’ number is 
zero, and the program ends. The computer goes back to its waiting 
state, ready for another command. 

It’s not quite so simple as that description makes it sound, but the 
essentials are there. The important thing to realise is that there isa 
lot of action to be done, and it has to be done one step at a time. 
What makes BASIC slow is that each token calls up a subroutine, 
which has to be found. For example, if you have a program that 
consists of a loop like: 


1? FOR N=1 TO 50 
20 PRINT N 
30 NEXT 


then the action of reading the PRINT token of 186, and finding 
where the correct subroutine is stored, will be carried out 50 times. 
There is no simple way of ensuring that the subroutine is located 
once and then just used 50 times. The kind of BASIC that you have 
on your Oric/ Atmos is ‘interpreted’ BASIC which means that each 
instruction is worked out as the computer comes to it. If that means 
finding the address of the PRINT subroutine 50 times, so be it. The 
alternative is a scheme called compiling, in which the whole program 
is converted to efficient machine code before it is run. Compiling is 
done using another program, called a compiler. The use of a 
compiler fora BASIC program very greatly speeds up the running of 
the program, but it makes the program less easy to edit, because it 
converts the program into a different form. You can’t win them all! 





Chapter Three 
The Microprocessor 


In this chapter, we'll start to get to grips with the 6502 
microprocessor of the Oric/ Atmos. The microprocessor, or MPU 
is, you remember, the ‘doing’ part of the computer as distinct from 
the storing part (memory) or the input/output part (ports), so that 
what the microprocessor does will control what the rest of the 
computer does. 

The MPU itself consists of a set of memory stores for numbers, 
but with a lot of organisation added. By means of circuits that are 
very aptly called ‘gates’, the way in which bytes are transferred 
between different parts of the MPU’s own memory can _ be 
controlled, and it is these actions that constitute the addition, 
subtraction, logic and other actions of the MPU. Each of the actions 
is programmed. Nothing will happen unless an instruction byte is 
present in the form of a | ora @ signal at each of the 8 data terminals, 
and these bytes are used to control the gates inside the MPU. What 
makes the whole system so useful is that because the program 
instructions are in the form of electrical signals on eight lines, these 
signals can be changed very rapidly. The speed is decided by another 
electrical circuit called a ‘clock-pulse generator’, or ‘clock’ for short. 
The speed that has been chosen as standard for the clock of the 
Oric/ Atmos is very fast, so that something like a million operations 
can be carried out per second. 


Machine code 


The program for the MPU, as we have seen, consists of number 
codes, each being a number between @ and 255 (a single-byte 
number). Some of these numbers may be instruction bytes which 
cause the MPU to do something. Others may be data bytes, which 
are numbers to add, or store or shift, or tokens, or just ASCII codes 
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for letters. The MPU can’t tell which is which - it simply does as it is 
instructed. It’s up to the programmer to sort out the numbers and 
put them into the correct order. 

The correct order, as far as the MPU is concerned, Is quite simple. 
The first byte that is fed to the MPU after switching on or after 
completing an instruction, is taken as being an instruction byte. 
Now several of the 6502 instructions consist of just one byte, and 
need no data. Others may be followed by one or two bytes of data, 
and some instructions need two bytes. When the MPU reads an 
instruction byte, then, it analyses the instruction to find if the 
instruction is one that has to be followed by one or more other bytes. 
If, for example, the instruction byte is one that has to be followed by 
two data bytes, then when the MPU analyses the first byte, it will 
treat the next two bytes that are fed to it as being the data bytes for 
that instruction. This action of the MPU is completely automatic, 
and is built into the MPU. The snag is that the machine code 
programmer must work to the same rules, and get the program right. 
100% correct is just about good enough. If you feed a 
microprocessor with an instruction byte when it expects a data byte 
or with a data byte when it expects an instruction byte, then you'll 
have trouble. Trouble nearly always means an endless loop, which 
causes the screen to go blank and the keys to have no effect. Even the 
RESTORE button can sometimes fail to break the Oric/ Atmos out 
of such a loop, and the only remedy is to switch off. You will 
generally lose whatever program you had in store, so it’s vitally 
important to save any machine code program, ora BASIC program 
that causes machine code actions (by using POKE) on tape before 
you use it. 

What I want to stress at this point is that machine code 
programming is tedious! It isn’t necessarily difficult - you are 
drawing up aset of simple instructions fora simple machine - but it’s 
often difficult for you to remember how much detail is needed. 
When you program in BASIC, the machine's error messages will 
keep you right, and help to detect mistakes. When you use machine 
code, you’re on your own, and you have to sort out your own 
mistakes. In this respect, a type of program called an ‘assembler’ 
helps considerably. We'll look at that point again later. In the 
meantime, the best way to learn about machine code is to write it, 
use it, and make your own mistakes. We'll start looking at how this is 
done, and we'll begin with the ways of writing the numbers that 
constitute the bytes of a machine code program. 
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Binary, denary and hex 


A machine code program consists of a set of number codes. Since 
each number code is a way of representing the 1’s and @’s ina byte, it 
will consist of numbers between # and 255 when we write it in our 
normal scale of ten (denary scale). The program is useless until it is 
fed into the memory of the Oric/ Atmos, because the MPU is a fast 
device, and the only way of feeding it with bytes as fast as it can use 
them is by storing the bytes inthe memory, and letting the MPU help 
itself to them in order. You can’t possibly type numbers fast enough 
to satisfy the MPU, and even methods like tape or disk are just not 
fast enough. 

Getting bytes into the memory, then, is an essential part of making 
a machine code program work, and we shall look at methods in 
more detail later on. At one time, simple and very short programs 
would be put into a memory by the most primitive possible method, 
using eight switches. Each switch could be set to give a | or @ 
electrical output, and a button could be pressed to cause the memory 
to store the number that the switches represented, and then select the 
next memory address. Programming like this is just too tedious, 
though, and working with binary numbers of I’s and 9’s soon makes 
you cross-eyed. Now that we have computers, it makes sense to use 
the computer itself to put numbers into memory, and an equally 
obvious step is to use a more convenient number scale. 

Just what is aconvenient number scale is a matter that depends on 
how you enter the numbers and how much machine code 
programming you do. The Oric/ Atmos contains subroutines which 
convert the binary numbers in its memory to the form of denary 
numbers to print on the screen, and will also carry out the reverse 
action. When you use PEEK, the address that you want can be 
written in denary, and the result of the PEEK will be a number in 
denary, between § and 255. When you use POKE, similarly, you can 
type both the address number and the byte to be poked in denary. 

Serious machine code programmers, however, find the use of 
denary anything but convenient. A denary number fora byte may be 
one figure (like 4) or two (like 17) or three (like 143). A much more 
convenient code is the one called hex (short for hexadecimal) code. 
All one-byte numbers can be represented by just two hex digits. In 
conjunction with this, serious machine code programmers write 
their programs in what is called assembly language. This uses 
command words which are shortened versions of the names of 
commands to the MPU. Programs that are called assemblers then 
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convert these command words into the correct binary codes. 
Practically all assemblers show these codes on the screen in hex 
form rather than in denary. In addition, when you type data 
numbers, you will have to make use of hex code. ‘Hexadecimal’ 
means scale of sixteen, and the reason that it is used so extensively is 
that it is naturally suited to representing binary bytes. Four bits, half 
of a byte, will represent numbers which lie in the range 9 to 15in our 
ordinary number scale. This is the range of one hex digit (Fig. 3.1). 


Hex Denary Hex Denary 
9 ‘e 12 
l l D 13 
Ze 2 E 14 
3 3 F 15 
4 4 then 
5 5 19 16 
6 6 11 17 
7 7 to 
8 8 20 32 
9 9 21 33 
A 10 ae 34 
B 11 etc. 





Fig. 3.1. Hex and denary digits. 


Since we don’t have symbols for digits higher than 9, we have to use 
the letters A,B,C,D,E, and F to supplement the digits 9 to 9 in the 
hex scale. The advantage is that a byte can be represented by a two- 
digit number, and a complete address by a four-digit number. 

The number codes that are used as instructions have been 
designed in hex code, so that we can see much better how commands 
are related. For example. we may find that a set of related 
commands all start with the same digit when they are written in hex. 
In denary, this relationship would not appear. In addition, it’s much 
easier to write down the binary number which the computer actually 
uses when you see the hex version. The use of the Oric/ Atmos 
assembler and monitor programs, such as the Oricmon Editor/ 
disassembler/ assembler, demands familiarity with hex, and books of 
information on the 6502 MPU will all be written assuming that you 
know hex. It sounds as if we ought to make a start on it! 
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The hex scale 


The hexadecimal scale consists of sixteen digits starting, as usual, 
with § and going up in the usual way to 9. The next figure is not 19, 
however, because this would mean one sixteen and no units, and 
since we aren’t provided with symbols for digits beyond 9, we use the 
letters A to F. The number that we write as 1@ (ten) in denary is 
written as 9A in hex, eleven as 9B, twelve as 9C and so on up to 
fifteen, which is §@F. The zero doesn't have to be written, but 
programmers get into the habit of writing a data byte with two digits 
and an address with four even if fewer digits are needed. The number 
that follows @F is 19, sixteen in denary, and the scale then repeats to 
1F (thirty-one) which is followed by 29 (thirty-two). The maximum 
size of byte, 255 in denary, is FF in hex. 

When we write hex numbers, it’s usual to mark them in some way 
so that we don’t confuse them with denary numbers. There’s not 
much chance of confusing a number like 3E with a denary number, 
but a number like 26 might be hex or denary. The convention that Is 
followed by 6502 programmers is to use the dollar sign ($) to marka 
hex number, with the sign placed before the number. For example, 
the number $47 means hex 47, but plain 47 would mean denary 
forty-seven. When you write hex numbers for a 6502 program, it’s 
advisable to follow this convention. 


Hex Binary Hex Binary 
0 9000 8 1990 
l 9901 9 1901 
2 P19 A 1D 19 
3 O11 B 1011 
4 0190 C 1190 
5 0191 D 1191 
6 P1190 E 1119 
7 M111 F 1111 


Fig. 3.2. Hex and binary digits. 


Now the great value of hex code is how closely it corresponds to 
binary code. If you look at the hex-binary table of Fig. 3.2, you can 
see that $9 is 191 in binary and $F is 1111. The hex number $9F is 
therefore just 19911111 binary —- you simply write down the binary 
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digits that correspond to the hex digits. The conversion in the 
opposite direction is just as easy — group the binary digits in fours, 
starting at the least significant (right-hand side of the number) and 
then convert each group into its corresponding hex digit. Figure 3.3 
shows examples of the conversion in each direction so that you can 
see how easy it is. 


Conversion: Hex to Binary 

Example: 2CH 

2H is 9910 binary 

CH is 1199 binary 

So 2CH is 99191199 binary (data byte) 


Example: 4A7FH 

4H is 9100 binary 

AH is 1919 binary 

7H is O111 binary 

FH is 1111 binary 

So 4A7FH ts PINPIMIMDOILITIIT binary (an address) 


Conversion: Binary to Hex 
Example: 91191911 

1911 is BH 

0119 is6H 

So O1IOIDTI is 6BH 


Example: 1OD11O 19919919 (note that this is not a complete number of 
bytes). 

Group into fours, starting with Isb: 

0010 is 2H 

INO1 is 9H 

O11) is 6H and the remaining | is 1, making 1692H 





Fig. 3.3. Converting between hex and binary. 


The Oric/ Atmos has built-in programs for converting between 
denary and hex. These are forced into action by the use of two 
‘commands’, the symbol # (hashmark) and the word HEXS. Taking 
these in order, # has the effect of converting a hex number into 
denary. If you want to poke a number into the memory of the 
Oric/Atmos you musr use denary, because all the systems of the 
machine are geared to convert denary numbers into binary. The 
machine will therefore work happily with the number 162, taking 
this as a denary number, but it won't recognise that A2 is the same 
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number. If you type #A2, however, the computer will convert this 
into denary 162 and work with it. This can be confusing, because the 
sign # is used in other ways, and you will have to be careful, later on, 
about how you use the sign. You must 7o/ use the §$ sign in your hex 
numbers, even though it is often found in listings, because the 
machine cannot deal with it. 

The opposite conversion, from denary to hex, is done by using a 
string, HEX$. HEX$ has to be followed by a number, within 
brackets, and the result will be the hex equivalent of that number. If, 
for example, you type: 


PRINT HEX$(162) 


and press RETURN, you will see the result A2 on the screen, the hex 
equivalent of denary 162. Having these two conversion methods 
built into the computer makes it very easy to design programs that 
print hex numbers, or which allow you to input hex numbers. 

There’s just one little twist to the use of hex. Suppose you havea 
string variable, D$, which has been allocated to a hex number. How 
do you print its denary value? The answer is to use VAL and # to 
convert the number, first into a denary string, then into a number. 
For example, if D$ = “A2”, then PRINT VAL(“#” + DS) will give 
162, the denary value. The importance of this is that if you keep a set 
of hex numbers in a DATA line, you don’t have to use: 

DATA #A2,#11,4#F3,4#4A 


and so on, but simply: 


DATA A2,11,F3,4A 
which saves you quite a lot of typing. Just in case you want to do 
these conversions when you are not near a friendly Oric/ Atmos, 
though, the methods are shown in Appendix B. 

Assuming, which is reasonable, that you don’t want to commit 
yourself to the cost of a full-scale assembler at this point, what do 
you do to create machine code programs? The answer is that you 
design your program in assembly language, which is by far the 
easiest way to design machine code programs, and then you convert 
into hex code. Converting means looking up - ina set of tables called 
the instruction set -the hex number that represents each instruction. 
Instruction sets are provided by the manufacturers of all 
microprocessors, and Mostek, who designed the 6502, provide one 
for this chip. Just to assist you, a quick-reference guide has been 
included in this book, in Appendix B. Don’t refer to it at the moment 
— it'll put you off! 
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Useful as these denary-hex conversion programs for the Oric/ 
Atmos are, they are deficient in one respect - they don’t handle 
negative numbers. Now this is unfortunate, though understandable. 
Negative numbers are very important in machine code programs, 
particularly if you are working without an assembler. The reason is 
that you sometimes want the MPU to do the equivalent of aGOTO, 
perhaps jumping to a step which is 30 steps ahead of its present 
address. This sort of thing is usually programmed by supplying a 
data number which is the number of steps that you want to skip. If 
you want to jump back to a previous step, however, you will need to 
use a negative number for this data byte. This is very common, 
because it’s the way that a loop is programmed in machine code. We 
need, therefore, to know how to write a negative number in hex. 

What makes it awkward is that there is no negative sign in hex 
arithmetic. There isn’t one in binary either. The conversion of a 
number to its negative form is done by a method called 
complementing, and Fig. 3.4 shows how this is done. At first sight, 
and very often at second, third, and fourth, it looks entirely crazy. 
When you are dealing with a single byte number, for example, the 
denary form of the number —1 is 255! You are using a large positive 
number to represent a small negative one! It begins to make more 
sense when you look at the numbers written in binary. The numbers 
that can be regarded as negative all start with a | and the positive 
numbers all start witha @. The MPU can find out which is which just 
by testing the left-hand bit, the most significant bit. 

It’s a simple method, which the machine can use efficiently, but it 
does have disadvantages for humans. One of these disadvantages Is 
that the digits of a negative number are not the same as those of a 
positive number. For example, in denary, —49 uses the same digits as 
+49. In hex, —49 becomes $D8 and +49) becomes $28. The denary 
number —85 becomes $AB and +85 becomes $55. The second 
disadvantage is that humans cannot distinguish between a single 
byte number which is negative and one which is greater than 127. 
For example, does $9F mean 159 or does it mean —97? The short 
answer is that the human operator doesn’t have to worry. The 
microprocessor will use the number correctly no matter how we 
happen to think of it. The snag is that we have to know what this 
correct use is in each case. Throughout this book, and in others that 
deal with machine code programming, you will see the words 
‘signed’ and ‘unsigned’ used. A signed number is one that may be 
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OEE Ne ee ee ee aR pe RE ee sept ee a ee ee 
Binary. Number (8 bits): PO1IGIP! (denary 53) 


Step 1: change each () to 

I, each | to 0 11991919 
Step 2: add | a | 
The result is the negative 


form of number 11991911 (denary 263) 

Denary. Number 53 

Step 1: subtract from 256 203 

This is negative form (in denary) 

Hex. Number $35 {Remember that F 
represents 15 

Step 1: subtract from $FF FF }denary, and 


35 }15-5= 19 
SCAfdenary, which 
is Ain hex. 
Step 2: add | +1 | This is easier 
SCB \than a subtraction 
~ Mrom $199, which 
involves the use 
of carries in hex. 
The result is the hex form of negative number 


An alternative is to do the denary conversion, then convert back to hex. 


Fig. 3.4. The two’s complement, or negative form, of a binary number. 


negative or positive. For a single byte number, values of #) to $7F are 
positive, and values of $89 to SFF are negative. This corresponds to 
denary numbers () to 127 for positive values and 128 to 255 for 
negative. Unsigned numbers are always taken as positive. If you find 
the number $9C described as signed, then, you knowit’s treated asa 
negative number (it’s more than $80). If it’s described as unsigned, 
then it’s positive, and its value is obtained simply by converting. 
How do we convert a signed single-byte hex number into denary, 
using our programs? It’s simple: if the number is greater than $7F, 
then subtract 256 from its denary value. If you get 249 asa result, for 
example, then 240—256=— 16, and that’s the signed value in denary 
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Light relief 


Just to take a break from all this arithmetic let’s look at screen 
displays on the Oric/ Atmos. Each part of the screen can becontrolled 
by whatever is stored in part of the memory, but there are two 
varieties of this memory. The simplest one to work with is the part 
which is called ‘text screen memory’. It takes up memory addresses 
$BBA8 to SBFDF, which is 48949 to 49119 in denary. What we 
mean by ‘text screen memory’ is that this piece of memory is treated 
in a special way. Anything that is stored here will be used to display 
text on the screen. That means that any code number that you store 
at an address in this range will produce the corresponding letter or 
graphics shape on the screen. For example, if you clear the screen, 
using CTRL L, and then type 


POKE48619,65 


and then press RETURN, you will see the letter ‘A’ appear about the 
middle of the screen. In general, if you poke an ASCII code number 
to any of the correct screen addresses, you will see a letter appear. 

It’s not quite so simple as it all sounds, however, when you come 
to the first address for each column of the screen. Suppose we take 
48600, the first address in the line that we have already used. Try the 
effect of: 


POKE4869@,19 


It makes the line turn toa yellow background. The Oric/ Atmos uses 
this first column in each line of the text screen to place codes that 
affect the background colour of the rest of the line. If you use the list 
of colour codes in Fig. 3.5, then you can find the number that you 
need to poke into this first column address by adding 16 to the 
colour number. The colour that you will see as the background 
colour of the line will be given by this colour number. Now try this 
one. Clear the screen again, and POKE48619,65 to get the letter ‘A’. 
Now use POK E4869 1,6. This will make the letter ‘A’ appear in the 
colour cyan. These foreground colour pokes use the colour numbers 
of @ to 7 directly. 

You can program screen poke operations into a loop, as Fig. 3.6 
shows. You should restore normal screen conditions by using CTRL 
L first. The effect of this loop is to fill the screen with A’s. The filling 
is not particularly fast, because we're using BASIC in the loop. 
Later, we'll look at the same sort of thing in machine code, which is 
stunningly fast! For the moment, though, look at the effect on this 
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Number Colour 


Black 
Red 
Green 
Yellow 
Blue 
Magenta 
Cyan 
White 


“SHAUN DW pp —- oS 


Fig. 3.5. Foreground colour codes for the Oric/Atmos. You need to add 16 to 
the code number for background colour. 


1@ N1=48042: N2=48079: REPEAT 
2@ FORJ=N1TON2: POKEJ, 65: NEXT 
S@ N1=N1i+4@; N2=N2+4@ 

4@ UNTIL N1=49122 


Fig. 3.6. A program which fills the screen with the letter A. 


program of typing LORES], pressing RETURN, and then running 
the program. It’s quite useful, and if you want to avoid the ‘hole’ in 
the pattern caused by the READY message, then add an endless 
loop to the program, like: 


59 GOTO 59 


Note, however, when you use this with LORES1, you will see the 
graphics characters on the main part of the screen, but the letter Ain 
the ‘text window’ at the bottom of the screen. 

Now for the cream topping. Change your POKE program so that 
N1 = 48949. This means that the code number of 65 will be poked 
into the first two blocks in each line. What effect does it have? Justa 
complete screenful of ‘A’, that’s all! What’s more, you still get letter 
‘A’ whether you type LORES! or LORES®@. Not quite so simple 
after all, is it? What it amounts to is that you get a character 
whenever you poke a character code, anywhere in the screen 
memory. Poking a colour foreground or background code will also 
affect the screen. If, forexample, you POKE X, 19 in line 20 of Fig. 
3.6, you will see the whole screen turn yellow when you RUN. You 
would, however, get the same effect more economically by just 
poking the first column of each line. POKE, unlike PRINT, can 


The Microprocessor 39 


affect any column of the screen, but it’s only the first two columns 
which will affect all the rest of the screen. Now try making NI = 
48960. As you might expect, this affects the right-hand side of the 
screen, turning it yellow. Now clear the screen, and try the one-liner: 


FORN = 48966T049199STEP49:POKEN, 19:NEXT 


Now watch! This makes the right half of the screen turn yellow, and 
very much more quickly than the previous effort. The reason, which 
you probably know from BASIC, is that setting a colour ‘attribute’ 
number into any memory location affects all the rest of the line. This 
is one of the features which make the Oric/ Atmos such a delight to 
program. It also means that we have to be quite careful about what 
we poke, and where, on the screen! 





Chapter Four 


6502 Details 


Registers - PC and accumulator 


A microprocessor consists of sets of memories, which are called 
registers. These memories are of a rather different type compared to 
ROM or RAM. The registers are connected to each other and to the 
pins on the body of the MPU by the circuits that are called gaves. In 
this chapter, we shall look at some of the most important registers of 
the 6502 and how they are used. A good starting point is the register 
which is called the PC —- short for Program Counter. 

No, it doesn’t count programs - what it does is to count the steps 
in a program. The PC is a sixteen-bit (two-byte) register which can 
store a full-sized address number, up to $F FFF (65535 denary). Its 
purpose is to count the address number, and the number that is 
stored in the PC will be incremented (increased by 1) each time an 
instruction is completed, or when another byte is needed. For 
example, if the PC holds the address $1 F3A (denary 7994), and this 
address contains an instruction byte, then the PC will increment to 
$1F3B (denary 7995) whenever the MPU is ready for another byte. 
The next byte will then be read from this new address. 

What makes the PC so important is that it’s the automatic way by 
which the memory is used. When the PC contains an address 
number, the electrical signals that correspond to the 9's and I's of 
that address appear on a set of connections, collectively called the 
address bus, which link the MPU to all of the memory, RAM and 
ROM. The number that is stored in the PC will select one byte from 
the memory, the byte which is stored at that address number. At the 
start of a read operation, the MPU will send out a signal called the 
read signal on another line, and this will cause the memory to 
connect up the selected parts to another set of lines, the data bus. 
The signals on the data bus then correspond to the pattern of §’s and 
I’s that is stored in the byte of memory that has been selected by the 
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address in the PC. Each time the number in the PC changes, another 
byte of memory is selected, so that this is the way by which the MPU 
can keep itself fed with bytes. When the MPU is ready for another 
byte, the PC increments, and another read signal is sent out. 

There are other ways in which the PC number can be changed, but 
for the moment we'll pass over that and look at another register, the 
accumulator. The accumulator of a microprocessor is the main 
‘doing’ register of the MPU. This means that you would normally 
use it to store any number that you wanted to transfer somewhere 
else, or add to or carry out any other operation upon. The name of 
accumulator comes from the way in which this register operates. If 
you have a number stored in the accumulator, and you add another 
number to it, then the result is also stored in the accumulator. The 
nearest equivalent in BASIC is using a variable A, and writing the 
line: 


A=At+N 


where N is a number variable. The result of this BASIC line is to add 
N to the old value of A, and make A equal this new value. The old 
value of A is then lost. The accumulator acts in the same way, with 
the difference that an accumulator can’t store a number greater than 
255 (denary). 

The 6502 has one accumulator register, often labelled as the A 
register. The importance of this is that it is used much more than the 
other registers, because so many actions can be carried out more 
quickly, more conveniently, or perhaps on/y, in the accumulator. 
When we read a byte from the memory, we usually place it in the 
accumulator. When we carry out any arithmetic or logic action, it 
will normally be done in an accumulator and the result also stored in 
the accumulator. 


Addressing methods 


When we program in BASIC, we don’t have to worry about memory 
addresses at all unless we are using PEEK or POKE. The task of 
finding where bytes are stored is dealt with by the operating system 
of the machine. When a variable is allocated a value in a BASIC 
program as, for example, by a line like: 


19 N= 12 


we never have to worry about where the number 12 is stored, or in 
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What form it happens to be stored. Similarly, when we add the line: 
20 K=N 

we don’t have to worry about where the value of N was stored or 
where we will store the value of K. Remembering our comparison 
with wall-building in Chapter 2, we can expect that when we carry 
Out machine code programming we shall have to specify each 
number that we use or, alternatively, the address at which the 
number is stored. This way in which we obtain a number, or finda 
place to store it, is called the ‘addressing method’. What makes the 
choice of addressing method particularly important is that a 
different code number is needed for each different addressing 
method foreach command. This means that each command exists in 
several different versions, with a different code for each addressing 
method. A list of all the 6502 addressing methods at this stage would 
be rather baffling, and for that reason has been consigned to 
Appendix C. What we shall do here is to look at some examples of 
selected addressing methods and the way that we write them in 
standard assembly language. 


Assembly language 


Trying to write down machine code directly as a set of numbers isa 
very difficult process which is liable to errors from beginning to end. 
The most useful way of starting to write a program is to write it ina 
set of steps in what is called assembly language (or assembler 
language). This is a set of abbreviated command words, called 
mnemonics, and numbers which are the data or address numbers. 
The numbers can be in hex or in denary, provided they are supplied 
to the computer in the correct form. Each line of an assembly 
language program indicates one microprocessor action, and this set 
of instructions is later ‘assembled’ into machine code, hence the 
name. 

The aim of each line of an assembly language program is to show 
the action and the data or address that is needed to carry out that 
action, just as when we make use of TAB in BASIC we need to 
complete the command with a number. The part of the assembly 
language that specifies what is to be done is called the operator, and 
the part which specifies what the action is done to or on is called the 
operand. A few instructions need no operand, and we'll look at some 
later. 
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An example makes this easier. Suppose we look at the assembly 
language line: 


LDA #$12 


The operator is LDA, a shortened version of LOAD A, meaning 
that the accumulator register A is to be loaded with a byte. The 
operand is #$12, of which the $12 means that this is 12 hexadecimal 
(eighteen), rather than twelve denary. The other mark, the 
hashmark #, is used to show the addressing method that is to be 
used, a method called ‘immediate addressing’. This is where some 
confusion can arise, because the Oric/ Atmos uses the hashmark to 
signal hex to denary conversion. Because of this, some assemblers 
for the Oric/ Atmos use IM to mean immediate, rather than #. For 
the moment, though, we'll stick to # in writing assembly language, 
because that’s what you'll see used in a lot of books that deal with 
6502 programming. It’s also the standard symbol that the 
manufacturers of the chip use. 

The whole line, then, should have the effect of placing the number 
$12 into the accumulator register A. It is the equivalent in machine 
code terms of the BASIC instruction: 


A= 18 (remember that $12 is denary 18) 


You could imagine that the memory which held the number was 
inside the microprocessor rather than part of the RAM memory, 
and was labelled with the naine of ‘A’. 

A command such as LDA #$12 is said to use immediate 
addressing, because the byte which is loaded into the accumulator 
must be placed in the memory byte whose address immiediately 
follows that of the instruction byte. It’s like leaving a note for your 
milkman that says ‘money in envelope next door’! There is one code 
number for the LDA # part of the whole instruction, and this byte is 
$A9, so that the hex sequence in memory of A9 12 will represent the 
entire command LDA #$12. It’s a lot easier to remember what LDA 
#$12 means that to interpret A9 12, however, which is why we use 
assembly language as much as possible. 

Immediate addressing like this can be convenient, but it tics you 
down to the use of one definite number and one fixed memory 
address. It’s rather like programming in BASIC: 


N = 4*12+ 3 
rather than 


N = A*B+C 
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In the first example, N can never be anything else but 51, and we 
might just as well have written: N= 51. The second example is very 
much more flexible, and the value of N depends on what values we 
choose for the variables A, Band C. Whena machine code program 
is held in RAM, then the numbers which are loaded by this 
immediate addressing method can be changed if we must change 
them, but when the program is held in ROM no change is possible - 
and that’s just one reason for needing other addressing methods. 
One of these other methods is absolute addressing. 

Absolute addressing uses a complete two-byte address as its 
operand. This creates a lot of work for the 6502, because when it has 
read the code for the operator, it will then have to read two more 
bytes to find the memory address at which the data is stored. It will 
then have to place this address in the PC, read in the data byte, carry 
out the operation, and then restore the next correct address into the 
PC. Figure 4.1 shows in diagram form what has to be done. An 
absolute-addressed operation is therefore a lot slower to carry out 
than an immediate one, but since any byte may be stored at the 
address which is specified, it’s easy to alter the data. 


Addresses co 
in hex a 85 


6 aC) 


+ start of instruction 


7F00 code for load accumulator, 
extended addressing 


[ey 


7F01 7F first byte of address 
forms address of S7FFE 
FE second byte of address 


+— end of instruction 


~ 
Tl 
Oo 
Nm 


next code 





byte which is loaded into accumulator 
after address $7F02 has been read 


Fig. 4.1. How the absolute addressing method works. 
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Suppose, for example, that we have the instruction: 


LDA $7FFE 


In this slice of assembly language, the operator is LDA (load the 
accumulator) and the operand is the address $9620. What you have 
to remember is that what is put into the register A is not 9629, which 
is a two-byte address, but the data byte which is stored in memory al 
this address. The effect of the complete instruction, then, is to place a 
copy of the byte which is stored at $9629 into the accumulator A of 
the 6502. When the instruction has been completed, the address 
$9620 will still hold its own copy of the byte, because reading a 
memory does not change the content of the memory in any way. 

We can also use the absolute addressing method in a command 
which will store a byte into the memory. The command: 


STA $9620 


means that the byte that is stored in the accumulator A is to be 
copied to memory at address $9620. This action will change the 
content of this memory address, but the accumulator A will still hold 
the same byte after the instruction has been carried out. 


Zero page addressing 


Zero page addressing is a method that allows you to specify a full 
address by using only one byte! The secret is that the upper byte of 
the address is taken to be zero. This is how we get the name of zero 
page for this type of addressing. Suppose, for example, that we used 
the command: 


LDA $3F 


There’s no # sign here, so it does not mean that we load the number 
$3F into the accumulator. What it does mean is that we load the 
accumulator with the byte that has been stored in the address 
$993. The 0@ part is the zero page, and the 3F part is the part that 
we have specified in the instruction. The range of addresses that we 
can use with this method is from $0999 to SOMFF only. This is only 
256 (denary) bytes, but it’s a very important 256 bytes. In denary, it’s 
addresses 9 to 255 — you can see an advantage of using hex here, 
because if you looked only at the denary numbers, you would 
wonder why the words ‘zero page’ were used. In the 6502, zero page 
addressing allows us to get access to any of these addresses very 
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rapidly, and with only one byte of address (the lower byte). This 
makes these addresses the favoured ones for any programmer who 
wants to carry out rapid loading and storing. For this reason, the 
‘zero page’ addresses of the RAM in any 6502 machine are favourites 
for storing important quantities. We have already seen them being 
used for storing quantities like the address of the start of BASIC and 
the address of the Variable List Table. The same addresses are used 
for all sorts of important quantities, and as we go on in this book, we 
shall look at several of them in more detail. Because the Oric/ Atmos 
makes a lot of use of zero page addresses for its own purposes, we 
have to be careful how we make use of them in our own programs. If 
we try to use an address that the computer needs, we may lock up the 
whole system. That's just one reason why it’s so important to record 
a machine code program before you try it out. 


Indexed addressing 


Indexed addressing is a method which is particularly useful on the 
6502. The principle is that an eight-bit register is used to hold a byte. 
This byte is then added to a base address when the indexed 
addressing is used. A base address means an address to which we can 
add a number before using it. For example, suppose that we had the 
number $4C stored in an index register. If we then specify that we 
want to load from an address $7000 with indexing, then what 
happens is that the number in the index register is added to the 
address $7000). This makes the address number $704C, and this is 
the number that will be used as the address number. The effect is that 
the byte in address $704C will be loaded into the accumulator. 

There are two registers in the 6502 that can be used in this way, the 
X and Y registers. They are both eight-bit registers, and they are 
almost identical, but there are some differences that will be more 
important to you later on. One of the differences that we can look at 
immediately is zero page indexed addressing. When we load the X 
register with a byte such as $4A, and then issue the command (in 
assembly language): 


LDA $7000,X 
this means that the address that is to be used is $79 plus the 
contents of the X register. The result is that the address $794A is 
used. This is absolute indexed addressing. *Absolute’ means that we 
are using absolute addressing for the ‘base address’ of $7009, and we 


— 
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are then adding the ‘index’ number of 4A from the X index register. 
We can use the Y index register of the 6502 in exactly the same way, 
with instructions such as: 


LDA $7969.Y 


in assembly language. The use of the X index register, however, 
allows us to use zero page indexed addressing. We can, for example, 
use assembly language commands such as: 


LDA S$C,X 


This means that the base address is $#9@C, and that the number 
stored in the X register will be added to $O@OC before use. If the 
number stored in the X register is $23, then $@99C + $23 gives 
$902F, and this is the address number that will be used. The 
accumulator will therefore be loaded from address $#(2F. Zero 


page indexed addressing cannot be used with the Y-index register, so 
a command such as: 


LDA $IF,Y 


is impossible ~ there is no instruction code for it. 

Now the use of indexed addressing might not seem particularly 
useful at first sight. All you are doing, after all, is to add a number to 
an address. What makes the method so very useful is that you can 
alter the number that is stored in the X or Y registers. More 
particularly, you can increment or decrement the number in either of 
these index registers. The command INX means ‘increment X’. Its 
effect is to add one to the number that is stored in the X register. 
Now since the number in the X register is added to a ‘base address’ 
when we use indexed addressing, incrementing X means that we 
shall increment the address that we get from an X-indexed load or 
store operation. Suppose, for example, that you wanted to store ten 
bytes at ten consecutive addresses. It’s a very common problem, 
because it’s just what you need to do to print ten characters on the 
screen, forexample. The use of indexing means that you can set upa 
loop which will store, using indexing, then increment the index and 
repeat the store operation. Carry this out fora total of ten times, and 
the action is complete. Perhaps it’s a bit early to mention the use ofa 
loop, but we'll soon come to it. The example isa useful one, because 
it illustrates one of the most common uses for indexed addressing. 

In addition to incrementing the X and Y registers (mnemonics 
INX, INY), we can decrement these registers. The assembly 
language command DEX means decrement X (subtract | from the 
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number stored in X), and DEY means decrement Y. Since we have 
two index registers it's even possible to load from one base address, 
X-indexed, and then increment X. The byte that has been loaded can 
then be stored, indexed to the Y register this time and using another 
base address. The Y register can then be incremented. If all this is 
done in a loop, the effect will be to place bytes from a set of 
addresses, moving up from a starting address, into another set of 
addresses, moving up from another starting address. Complicated, 
you think? It might sound so in words, but in fact it’s a very simple 
and neat method of shifting bytes from one part of memory to 
another, and that’s an operation which is very often essential in 
computing. It can, forexample, allow you to shifta BASIC program 
from one part of memory to another so that you can load in another 
program without losing the BASIC one. 


Indirect addressing 


Indirect addressing means going to an address to pick up another 
address at which a byte is located. It’s like going to the address of a 
tourist office to find the address of a hotel (for a quick byte?). The 
6502 allows two main forms of indirect addressing to be used. These 
are relatively complicated, and we won't make much use of them in 
this book, because this is an introduction, not an encyclopaedia. We 
can, however, look at the principles that are involved, because the 
two indirect methods are similar in many respects. The principle is to 
make use of the zero page addresses in pairs. In any of these pairs, we 
can store an address in two bytes. The order of the bytes is the one 
that should be familiar to you by now, low-byte and then high-byte. 
An indirect addressing method makes use of the first of a pair of 
these zero page addresses. The effect of acommand which makes use 
of indirect addressing is therefore to read the byte in the first of the 
zero page addresses, and place this into the lower half of the 
Program Counter register. The next zero page address is then read, 
and the byte in it is put into the higher half of the Program Counter. 
The Program Counter now contains a full address, and this is used 
for loading or storing, depending on which operation has been 
specified. For example, if address $19 contained $99 and address 
$11 contained $39. then the effect of an indirect load from $19 
would be to place the address $300 into the Program Counter, and 
so load the accumulator with the byte that is stored at $3999. Once 
again, it seems very complicated and unnecessary until you realise 
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the special advantages of such a method. The special advantage is 
that you can alter the address that is used by altering numbers stored 
in the zero page memory. The operating system of the Oric/ Atmos 
makes use of indirect addressing along with the addresses that are 
stored in its page zero part of RAM. The indirect addressing 
methods of the 6502 are, in fact, rather more complicated than I 
have indicated here, because the index registers are also used. One of 
the indirect addressing methods is illustrated inexamples in Chapter 
7 and in Chapter 9. 


Relative addressing 


Relative addressing is one of the first addressing methods that was 
ever used, and it is not used for many commands nowadays. Relative 
addressing means that the operand of an instruction can be one or 
two bytes, and the address that is going to be used is found by adding 
this number (called the offset) to the ‘current address’, which is the 
number in the Program Counter. It’s rather like the old-style 
Treasure Island maps which specify ‘one step left, two forward, three 
right ....and so on. You don’t know where this will get you until you 
know where to start, but when relative addressing is used in a 
microprocessor, the starting place is usually the address in the PC. 
The 6502 uses relative addressing only for its BRANCH commands, 
and the offset is a single byte which is treated as a signed number. 
The use of a single byte signed number means that we can jump toa 
new address which is up to 127 steps forward or 128 steps back from 
the present one. These branches are the machine code equivalents of 
GOTO, but with the difference that they can be made to depend ona 
condition, like the accumulator containing zero. It’s as if there were 
one single BASIC instruction which carried out the effect of: 


IF A= 9 THEN GOTO... 


We'll look at branch instructions in a lot more detail later. 


The other registers 


Of the other registers, the S register is an eight-bit register that we 
shall leave strictly alone for the moment. It is the type of register that 
is called a ‘stack pointer’, and it is used to locate bytes which the 
MPU has stored temporarily. If you interfere with what is stored in 
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the S register, you may upset the operating system of the computer. 
The other register that is important to us is the Processor Status (P) 
register and we'll deal with it in more detail now. The Processor 
Status register, sometimes called the Flag register, isn’t really a 
register like the others. You can’t do anything with the bits in this 
register, and they don't even fit together as a number. 

What the Process Status register is used for is as a sort of 
electronic note-pad. Seven of the bits in the register (there are eight 
of them altogether) are used to record what happened at the 
previous step of the program. If the previous step was a subtraction 
which left the A register storing zero, then one of the bits in the 
Process Status register will go from value @ to value | to bring this to 
the attention of the MPU. If you add a number to the number in an 
accumulator, and the result consists of nine bits instead of eight (Fig. 
4.2) then another of the bits in the Process Status register is ‘set’, 
meaning that it goes from @ to I. If the most significant bit ina 
register goes from @ to | (which might mean a negative number), 
then another of the Process Status bits is set. Each bit, then, is used 
to keep a track of what has just happened. What makes this register 
important is that you can make branch commands depend on 
whether a Process Status bit is set (to 1) or reset (to @). 


Number in accumulator IPLIOIIO 
Number added 119PO101 
Result IMTITIOII 


This consists of nine bits, and the accumulator can 
hold only eight. The most significant bit is trans- 
ferred to the carry flag of the status register. 


Accumulator now holds §1111611 
Carry bit is set (equal to 1) 


Fig. 4.2. Why the carry bit is needed. 


Figure 4.3 shows how the bits of the Process Status register of the 
6502 are arranged. Of these bits, §,1 and 7 are the ones that we are 
most likely to use at the start of a machine code career. The use of the 
others is rather more specialised than we need at the moment. Bit @ is 
the Carry Flag. This is set (to 1) ifa piece of addition has resulted ina 
carry from the most significant bit of a register. If there is no carry, 
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| | | | 


Negative 
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used mode 


Overflow Break Interrupt Carry 














Fig. 4.3. The bits of the Processor Status register. Only three of these, N, Z, 
and C, are extensively used in most programs. 


the bit remains reset. When a subtraction is being carried out (ora 
similar operation like comparison), then this bit will be used to 
indicate if a ‘borrow’ has been needed. It can for some purposes be 
used as a ninth bit for either accumulator, particularly for shift and 
rotate operations in which the bits in a byte are all shifted by one 
place (Fig. 4.4). 


Carry A 
bit msb ccumulator Isb 


[sfofols}ols{s fol 
<= = 


After a left shift. the bits 
will be: 
Carry 
bit msb Accumulator Isb 


fof ols] oj s}sjofo| 


Fig. 4.4. Using the carry bit in a shift operation, in which all the bits of a byte 
are shifted one place to the left. 


The Zero Flag is bit I. It is set if the result of the previous 
operation was exactly zero, but will be reset () otherwise. It’s a 
useful way of detecting equality of two bytes — subtract one from the 
other, and if the Zero Flag is set, then the two were equal. The 
Negative Flag is set if the number resulting in a register after an 
operation has its most significant bit equal to I. This is the type of 
number that might be a negative number if we are working with 
signed numbers, or if we want to test that one number is bigger than 
another. This bit is therefore used extensively when we are working 
with signed numbers. 

You can alter some of the bits of the Process Status register 
selectively - but that’s not beginner's work! For the most part, we 
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don’t load anything into this register, or store its content. It is used 
almost exclusively as a way of keeping track of what has just been 
done, and that’s how we shall illustrate its use in this book. Other 


dodges can wait until you’re an expert. 


Chapter Five 
Register Actions 


Accumulator actions 


Since the accumulator is the main single-byte register, we must now 
list its actions and describe them in detail. Of all the accumulator 
actions, simple transfer of a byte is by far the most important. We 
don’t, for example, carry out any form of arithmetic on ASCII code 
numbers, so that the main actions that we perform on these bytes are 
loading and storing. We load the accumulator with a byte copied 
from one memory address, and store it at another. Very few 
computer systems allow a byte to be moved directly from one 
address to another, so that the rather clumsy-looking method of 
loading from one address and storing to another is used almost 
exclusively. 

The next most important group of actions is the arithmetic and 
logic group, which contains addition, subtraction, AND, and OR. 
We can add to this group the SHIFT and ROTATE actions which 
we looked at briefly in the previous chapter. The effects of the 6502’s 
shift and rotate commands, with their assembly language mnem- 
onics, is shown in Fig. 5.1. A shift always results in a register losing 
one of its stored bits, the one at the end which is shifted out Both 
types of shifts cause the register to gain a zero at the opposite end. 
The carry bit is used as a ninth bit of the accumulator in both of these 
shifts. The shift action can be carried out on either the ‘A’ register 
(the accumulator) or on a byte that is stored in the memory. The 
effect of a shift on a binary number stored in the register is to 
multiply the number by two if the shift is left, or to divide it by two if 
the shift is right (Fig. 5.2). A rotation, by contrast, always keeps the 
same bits stored in the register, but the positions of the bits are 
changed. The 6502 has two rotate commands, one for rotate right 
and the other for rotate left. Once again, they use the carry bit as the 
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Accumulator or memory address 


ASL 
~|7[6|5|4|3]2/1|0]--@ 


AQis shifted into the Isb, and the msb is shifted into the carry bit 


LSR 
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Accumulator or memory address 
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AQis shifted into the msb and the Isb 1s shifted into the carry bit 





Accumulator or memory address 
Left rotation, using the carry bit 
ROR Accumulator or memory address 





Right rotation, using the carry bit 


Fig. 5.1. The 6502 shift and rotate instructions: ASL (Arithmetic Shift Left), 
LSR (Logic Shift Right), ROL (Rotate Left) and ROR (Rotate Right). 
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right shift 


ojo}i{ofrjrfof Hex 2D Denary 45 


Fig. 5.2. The effect of a shift on a number. 
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ninth bit of the register. Either the accumulator can be used, or the 
action can be carried out on a byte stored in the memory. 

The 6502, unlike most other microprocessor types, does not allow 
the accumulator to be used for increment or decrement actions. 
Increment means adding | and decrement means subtracting I. 
These actions can be carried out on bytes stored in the memory, 
though, so that the 6502 programmer can increment or decrement 
bytes before or after use. This may mean that a byte has to be 
returned to memory to be incremented or decremented. It’s just as 
easy, however, to use ADD immediate to perform an increment. An 
immediate subtract is not quite so simple, because the carry flag in 
the P register (the processor status register) must be set to | beforea 
subtraction is carried out. If the carry flag is not set, the result of 
subtracting | will be to subtract 2! The accumulator, however, can 
be used for the important comparison commands. 

The CMP (Compare) instruction is a particularly useful one. 
CMP is the mnemonic and it must use one of the standard memory 
addressing methods. The effect of CMP is to compare the byte that 
was copied from the memory with the byte that is already present 
and stored in accumulator A. Compare in this respect means that the 
byte copied from memory is subtracted from the byte in the 
accumulator. The difference between this instruction and a true 
subtraction is that the result is not stored anywhere! The result of the 
subtraction is used to set flags in the P register, but nothing else, and 
the byte in the accumulator is unchanged. For example.suppose that 
the accumulator contained the byte $4F, and we happen to have the 
same size of byte stored at address $327F. If we use the command: 


CMP $327F 


then the zero flag in the CC register will be set (to 1), but the byte in 
the accumulator will still be $4F, and the byte in the memory will 
also still be $4F. A subtraction would have left the content of the 
accumulator equal to zero. 

Why should this be important? Well, suppose you want a program 
to do one thing if the Y key is pressed, and something different if the 
N key is pressed. If you arrange for the machine code program to 
store into the accumulator the ASCII code for the key that was 
pressed, then you can compare it. By comparing it with $4E (the 
ASCII code for ‘N’), we can find if the N key was pressed. If it was, 
the zero flag will be set. If not, we can make another test. By 
comparing with $59, we can find if the Y key was pressed ~ once 
again, this would cause the zero flag to be set. If neither of these 
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comparisons caused the zero flag to be set, we know that neither the 
Y nor the N key was pressed, and we can go back and try again. Ifit 
looks very much like the action that you can program using the 
GETS loop in BASIC, you're right — it is. 

Finally, we have the test-and-branch actions. These, as the name 
suggests, allow the flags in the P register to be tested, and will make 
the program branch to a new address if a flag was set. Which flag? 
That depends on which branch-and-test instruction you use, 
because there’s a different one for each main flag, and for each state 
of a flag. For example, consider the two tests whose mnemonics are 
BEQ and BNE. BEQ means ‘branch if equal to zero’. As this 
suggests, it will cause a branch if the result of a subtraction or 
comparison is zero. In other words, it causes a branch to take place if 
the zero flag is set. Its ‘opposite number’, BNE, means ‘branch if not 
equal to zero’. It will cause a branch to take place if the zero flag Is 
not set. There are, therefore, two branch instructions which test the 
zero flag, but in opposite ways. The same sort of thing goes for 
several of the other flags. There’s also a different type of branch 
instruction, mnemonic JMP, which doesn’t carry out any tests, like 
a GOTO with no IF preceding it. 

The complete list of all the available branch instructions is shown 
in Fig. 5.3. Many of these are instructions that you'll probably never 
use, and the really important ones are the ones that use the zero, 
carry and negative flags. All of them, with the exception of JMP, use 
relative addressing. This means that one number byte must follow 
the code for the branch. This number is treated as a signed number 
(in other words, if it’s more than $7F, denary 127, it’s treated as 
negative) and is added to the address which is in the PC at the instant 
when the branch is carried out. The result of this addition is the 
address to which the branch goes, so the next instruction that is 
carried out will be the one at this new address. This type of branch, 
which uses a single byte ‘displacement’ number, permits a shift of up 
to 127 (denary) places forward, or 128 backward. That’s because a 
single signed byte can’t exceed these values. 


Interacting with Oric/ Atmos 


The time has come now to start some practical machine code 
programming of your Oric/ Atmos. This is not simply a matter of 
typing the assembly language lines as if they were lines of BASIC. 
Unless you happen to have an assembler program running, the 
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BCC Branch on carry clear: Jump to a new address if the carry flag is reset 
(at ). 

BCS Branch on carry set: Jump to a new address if the carry flag is set (at 
1). 

BEQ Branch if equal to zero: Jump to a new address if the zero flag is set (at 
1). 

BNE Branch if not equal to zero: Jump to a new address if the zero flag is 
not set (zero flag at @). 

BMI] Branch on result minus: Jump to a new address if the result of the 
previous operation was a negative number (N flag set). 

BPL Branch on result positive: Jump to a new address if the result of the 
previous operation was a positive number, or zero (N flag reset). 

BVC Branch on overflow clear: Jump to a new address if the overflow flag 
is @. 

BVS Branch if overflow set: Jump to a new address if the overflow flag is 
set. This will happen if the action of adding or subtracting causes the sign 
bit (the most significant bit) to change incorrectly. 


Note: All of the above instructions use PC-relative addressing. The 
command byte has to be followed by a single byte, called the displacement, 
which is added to the address in the Program Counter register to obtain the 
new address. 


JM P Jump to new address: Jump to the new address given by the two bytes 
that follow the JMP code. 


Fig 5.3. The complete list of 6502 branch instructions. 

Oric/ Atmos will simply give you the ‘SYNTAX ERROR’ message 
when you try to run these programs. Since we want to start on a 
small scale, we'll forget about assemblers at the moment, and 
assemble ‘by hand’. This means that we find the machine code bytes 
that correspond to the assembly language instructions by looking 
them up in a table. We then have to convert the hex codes and data 
numbers into denary numbers. We then poke these numbers into the 
memory of the Oric/ Atmos, place the address of the first byte into 
the PC of the 6502, and watch it all happen. It sounds simple, but 
there is quite a lot to think about, and a number of precautions to 
take. To start with, the Oric/ Atmos uses quite a lot of its RAM, as 
we have seen, for its own purposes. If we simply POKE a number of 
bytes into the memory without heeding which part of memory we 
use, the chances are that we shall either replace bytes that the 
Oric/ Atmos needs to use, or our program bytes will be replaced by 
the action of the Oric/ Atmos. What we need is a piece of memory 
that is safely roped off for our use only. 
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This can be done by making use of the fact that the Oric/ Atmos 
can reserve memory by using the BASIC instruction word HIMEM. 
The last byte of RAM that a program of your own can normally 
make use of is $9809 (denary 38912) for the 48K Oric or Atmos. For 
the 16K machines, the number is $1809 (denary 6144). Addresses 
right at the end of RAM memory like this are normally used for 
storing strings that are not already present lower in memory. We 
have already looked at this principle in Chapter 2. Now the 
Oric/Atmos is not programmed to stop at this number auto- 
matically. What is done is to store this ‘end-of-RAM’ number, as 
two bytes, in memory locations $A2 (low-byte) and $A3 (high-byte). 
These are zero page addresses, and in the course of operating a 
BASIC program, the computer will be continually testing that it 
does not try to use locations higher than the number stored in these 
addresses. You can find the HIMEM address in the usual way by 
peeking at the numbers in the usual way, but it’s time now to make 
use of a little Oric/ Atmos trick. If you use DEEK in place of PEEK, 
then you can carry out the peek of two addresses and the 
multiplication by 256 and addition that is needed to make up an 
address. Try, for example: 


PRINT DEEK(#A2) 


to find your HIMEM number. Easier, isn’t it? 

Suppose, then, that we alter this number. We don’t have to alter 
the bytes directly, though we could do so by using either POKE or 
DOKE. DOKE will alter both bytes, so as to place an address into 
them as two bytes in low-higher order. If we type: 


HIMEM 38399 


for the 48K machine, then we will have reserved memory address 
38406 to 38912 for our own uses. BASIC will not make use of any 
address higher than 38399, and therefore cannot interfere with our 
machine code programs. For a 16K machine, use HIMEMS5631 
instead of HIMEM38399. 

The other problem, then, is how to place the starting address for 
your program into the program counter of the 6502. Fortunately, 
the designers of the Oric/ Atmos have been kind to you. There is a 
BASIC command CALL which will do this for you. CALL has to be 
followed by a number, and this number will be placed into the PC. It 
will therefore be used as the address of the first byte of your 
program. Incidentally, I’ve taken this as meaning ‘starting byte’. It’s 
possible to write programs in which the first few bytes are data, so 
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that the program starts at, say, the tenth byte. This creates no 
problems; you simply use the address of the starting byte as the 
number for CALL. 

Lastly, for the moment at least, you have to ensure that your 
machine code program will stop in an orderly way. Nothing that we 
have done so far will indicate to the 6502 of the Oric/ Atmos where 
your program ends. As a result, the 6502 could continue to read 
bytes after the end of your program, until it encounters some byte 
which causes a ‘crash’. This might, for example, be a byte which 
causes an endless loop. Some programmers doubt if there are any 
bytes which do mor cause an endless loop in these circumstances! To 
return correctly to the operating system of the Oric/ Atmos, you 
need to end each machine code program with a ‘return from 
subroutine’ instruction, whose mnemonic is RTS and whose code is 
$69. 

There’s another headache that we don’t have to worry about at the 
moment. When you run a machine code program along with a 
BASIC program in your Oric/ Atmos, you are using the same 6502 
microprocessor for both jobs. It can’t cope with both at the same 
time, so it runs one, then the other. If you make use of the 6502 
registers in your machine code program, as you are bound to do, 
then you have to be quite certain that you are not destroying 
information that the BASIC program needs. For example, if at the 
instant when your machine code program started, the registers of the 
6502 contained the address of a reserved word in the ROM, then it 
will need this address in these registers when your machine code 
program ends. When a machine code program is called into action 
by using the CALL command, this is taken care of automatically. 
The contents of the registers of the 6502 are placed into a part of the 
RAM memory which is called ‘the stack’. This, incidentally, is 
another good reason for being careful as to where you place your 
machine code in the memory. If you wipe out the stack, the 
Oric/ Atmos will quite certainly not like it! The stack is located in the 
range of memory between addresses 256 and 511. When the RTS 
instruction is encountered at the end of your machine code, the bytes 
that have been stored in the ‘stack’ are replaced into their registers, 
and normal action resumes. If you call a machine code program into 
action by any other method, not using CALL. you may have to 
attend to this salvage operation for yourself as part of your machine 
code program. This involves using the PUSH and PULL commands 
- but more of that later. 
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Practical programs at last! 


With all of these preliminaries out of the way, we can at last start on 
some programs which are very simple, but which are intended to get 
you familiar with the way in which programs are placed into the 
memory of the Oric/ Atmos. You will also get some experience in the 
use of assembly language and machine code, and with how a 
machine code program can be run. 

We'll start with the simplest possible example — a program which 
just places a byte into the memory. In assembly language, it reads: 


ORG $9699; start placing bytes here 
LDA #$55; place hex 55 in accumulator 
STA $9614; store them at $9614 

RTS; go back to BASIC 


The first line contains a mnemonic, ORG, which you haven't seen 
before. It isn’t part of the instructions of the 6502, but it is an 
instruction to the assembler, which in this case is you! ORG is short 
for origin, and it’s a reminder that this is the first address that will be 
used for your program. We've chosen to use an address which leaves 
space for longer programs than we shall be writing in the course of 
this book, and we could have chosen a higher number. It will do as 
well as any other, however, and it leaves plenty of room for longer 
programs. When you program using an assembler, this line can be 
typed and the assembler will then automatically place the bytes of the 
program in the memory starting at this address. As it is, with 
assembly being done ‘by hand’ it simply acts as a reminder of what 
addresses to use. Note the comments which follow the semicolons. 
The semicolon in assembly language is used in the same way as a 
REM in BASIC. Whatever follows the semicolon is just acomment 
which the assembler ignores, but which the programmer may find 
useful. 

Now we need to look at what the program is doing. The first real 
instruction is to load the number $55 into the ‘A’ accumulator. This 
uses immediate addressing, so the number $55 will have to be placed 
immediately following the instruction. The hashmark, #, is used in 
assembly language to indicate that immediate loading is to be used. 
The next line commands the byte in the accumulator (now $55) to be 
stored at address $9614. In denary, this is 38420. It’s an address well 
above the ones that we shall use for the program. Obviously, we 
wouldn't want to use an address which was also going to be used by 
the program. This instruction uses absolute addressing. Finally, the 
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program ends with the RTS instruction, essential for ensuring that 
Oric/ Atmos life continues normally after our program ends. 

The next step in programming is to write down the codes in hex. 
Each code has to be looked up, taking care to select the correct code 
for the addressing method. The code for LDA immediate is $A9, so 
this is the first byte of the program which will be stored at address 
$9609, denary 38499. We can start a table of address and data 
numbers with this entry: 


38499 SAQ9 


and then move on. The byte that we want to load is $55, and this has 
to be put into the next memory address, because this is how 
immediate addressing works. The table now looks like this: 


38499 SA9 
38491 $55 


The next byte we need is the instruction byte for STA, with absolute 
addressing. This byte is $8D, and it has to be followed by the two 
bytes of the address at which we want the bytes stored. The address 
38429 translates into hex as $9614, so we can use the bytes $14 and 
$96 following the STA instruction. Remember that these bytes have 
to be in low-high order. The last code has to be the RTS code of $69, 
so that the table now looks as in Fig. 5.4. It uses addresses 38499 to 


Address (Denary) Byte (Hex) 
38400 SA9 
3840 1 $55 
38402 $8D 
38493 $14 
38404 $96 
38495 $60 


Fig. 5.4. The coded program, using denary addresses and hex bytes of data. 


38405, six bytes in all, and will place a byte into 38429, using denary 
numbers. Now we have to put it into memory and make it work! 

This requires a BASIC program which will reserve the memory, 
and poke the bytes in one by one. Since the Oric/ Atmos has its own 
hex-denary conversions, we can store the bytes in hex ina DATA 
line, and just poke them into place. There are two ways that this can 
be done, using POKE or DOKE. The POKE program is shown in 
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(a) 1@ HIMEMS8399: A=28400 
2@ FOR N=@ TO 5:READ Ds 
3@ POKE A+N, VAL ("#"+D$) 
4@ NEXT:CALL A 
5@ DATA A9,55,8D, 14,96, 68 


(b) 1@ HIMEM 28299: A=28400@ 

2@ FOR N=@TOSSTEP2:READ Ds 

=@ DOKE (At+N) , VAL ("#"+4+D$) 

4@ NEXT:CALL A 

3@ DATA SSA9, 148D, 6096 
Fig. 5.5. The BASIC program which puts the bytes into place: (a) using POKE 
(b) using DOKE. Note how the order of pairs of bytes has to be reversed to use 
DOKE. 
Fig. 5.5(a). By using HIMEM38399 we ensure that all memory 
addresses above 38388 are left unused by the Oric/Atmos. We 
declare the variable A as 38499, so that we can make use of this in 
the POKE commands. Lines 29 to 49 then poke data numbers into 
addresses that start at 38499. All of the codes have to be put into 
denary form for use with POKE, and this is done by using 
VAI (“#"+ DS) in the program. It’s better in many ways to work in 
hex as much as possible, and convert to denary only if you must. 
Since you have to make use of hex when you graduate to an 
assembler it’s as well to start getting familiar with the principles of 
working in hex now. 

The last program line, line 49, contains CALL A. This is the 
BASIC instruction which will cause your machine code program to 
run, with the start address specified as variable A. Line 5@ then 
contains the six bytes of data that we have worked out. When you 
RUN this, there’s no obvious effect. That's because you can’t see 
what’s in address $9614. If you use: 


2?PEEK(#9614) 


then you should find the value of 85, which is the denary version of 
$55, the number that the program put there. Now try this: type 
POKE#9614,255, press RETURN, and then delete the CALL 
instruction from your program. This is at the end of line 49. RUN 
the program again, and use ?PEEK(#9614) to find what's there. It 
should be 255. Now type CALL#9699 and press RETURN. Using 
?PEEK (#9614) should now give you 85 again. This is because poking 
the bytes of the program into memory won’t make the program run, 
only CALL does this. You can therefore poke values into memory 
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early in a BASIC program, and then make use of them later with a 
CALL wherever you like. 

Now this program isn’t an ambitious piece of work, it does no 
more than POKE#9614,#55 would doin BASIC, but it’s a start. The 
main thing at this point is to get used to the way in which machine 
code operates, and how you place it into memory and run it. 
Another point, incidentally, is that the machine code is safe in 
memory. If you type NEW (RETURN), the BASIC program will be 
cleared out, but your machine code remains. If you POKE#9614,255 
now, and test with 7PEEK(#9614), you will find that this address can 
still be changed by using CALL#9609@. These bytes will remain there 
until you make an effort to change them, or you switch off. You can 
preserve the machine code program on tape if you like, and this isa 
technique that we'll look at later. One step at a time, if you please! 
Another thing that we haven't space to cover is the alternative 
method of calling up a program, using the USR command. 

Before we leave this example, however, take a look at Fig. 5.5(b). 
This places the same bytes into the memory, but uses DOKE in place 
of POKE. DOKE has two effects. One is that it places two bytes into 
consecutive addresses, starting with the address that follows the 
DOKE command. The other effect is that the bytes are placed in the 
order that you would use for an address — low, then high. For 
example, if you use DOKE #960@,#10F4, then the byte $F4 is 
placed into address $9699. and the byte $19 is placed in address 
$9601. If we use DOKE, then, we have to group bytes into twos in 
the DATA line, and also alter the order of each pair. It’s something 
for later, when you are really accustomed to the 6502 way of doing 
things. 

Now let’s try something a lot more ambitious in terms of our use 


Assembly language Code 
LDX #S99 A2 09 
LDA $9620.X BD 20 96 
ASL A QA 

INX E8 

STA $9620,X 9D 20 96 
RTS 6() 


Fig. 5.6. The assembly language program for ‘multiply by two’. The listing 
shows the assembly language on the left, and the hex codes on the right. 
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of machine code - though the example is simple enough. Figure 5.6 
shows the assembly language version of the program. What we are 
going to do is to load a byte into the accumulator, shift it one place 
left, and then put it into memory at an address one step higher than 
the address from which we took it. This looks like an open-and-shut 
case for indexed addressing, so we shall start by placing a zero into 
the X register. This is the LDX #$0@ step. As before, the # in 
assembly language means immediate addressing - don’t mix it up 
with the way that the Oric/Atmos uses # for hex to denary 
conversion. The next line, LDA $9626,X means that the 
accumulator is to be loaded from the address $9629, plus the 
number in the X register. This makes the load from $9620 (38432 
denary). The third step is ASL A, arithmetic left shift of the byte in 
the accumulator, so that the bits of the byte are shifted left. 
Fourthly, we increment the number in the X register, using INX. 
This makes the 9 into 1, and we now store the byte in the 
accumulator at address $9621 by using STA 9620.X. This time, 
because | has been added to the number in the X register, the byte is 
stored at address $9621. We end. as always, with the RTS instruction. 

Now we can put this into code form. It’s just as easy as before, 
despite the use of indexing. The IDX instruction needs the 
immediate loading code of $A2, and this has to be followed by the 
byte of data, $99. The LDA with indexed addressing is coded as 
$BD, and it has to be followed by the two bytes of the address 
$9FC4, in their usual low-high order. The ASL byte is 0A, and then 
we perform the incrementing of X with INX, code $E8. We then 
store the byte that is in the accumulator back into memory, using 
STA $9629.X. The STA X-indexed code is $9D, and this is followed 
by the now familiar address bytes. Finally. $60 is the RTS 
command. 

Now we have to code this in BASIC. If we choose a small number 
to place into $9629, the effect of the left shift will be to double the 


1@ HIMEM 28399: A==z840e 
2@ FORN=® TO 1@:READ D¢% 

Z@ POKE A+N, VAL ("#"4+D4) 

4@ NEXT: POKE#962@,5:CALLA 

5@ DATAAZ2, @, BD, 24, 96, OA, ES, 9D, 24, 96, 40 
6@ PRINT"TWICE “PEEK (#962@)" IS "PEEK (# 
9621) 


Fig. 5.7. The BASIC program which pokes the bytes into place and then makes 
use of the machine code program. 
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number, so we can use this to obtain a bit of arithmetic wizardry. 
The BASIC program is shown in Fig. 5.7. We start, as usual, by 
clearing memory space. You needn’t worry if you have had another 
program in this part of the memory before. The new program will 
replace it completely, and provided that your program ends 
correctly with the RTS instruction byte, the old program bytes 
cannot interfere with the new ones. The values are poked into places 
in the usual way in lines 29 to 3@. In line 49, however, we place a 
number, 5 denary, into the address $9629. Now this is the address 
which will be used by the program, and the byte which is 5 in denary 
is, in binary form, 99909191. This byte will be placed in the address 
$9620. In the third part of line 49, CALLA will carry out the 
machine code program, which should left-shift this byte, making it 
P9OPIPIM. In denary, this is 19, twice 5. Line 69 prints this result, 
and line 59 contains the data bytes. 

It’s simple enough, but if you knew nothing about machine code, 
you would wonder how on earth the number became multiplied by 
two. Once again, the program does nothing that could not be done 
more easily and as quickly by using BASIC. The important thing, 
from our point of view, is that you have now used indexed addressing, 
and a shift instruction, as well as getting more experience in putting 
a machine code program into your Oric/Atmos by the hardest 
method of all. If, incidentally, you have made any mistakes, 
particularly with DATA, then it’s likely that the Oric/ Atmos will go 
into a trance and refuse to do anything. When you have typed ina 
BASIC program like this which pokes bytes into the memory, 
always record the BASIC program before you RUN it. This way, if 
the effect of an incorrect byte is to zonk out half the RAM, you can 
switch off, then on again, and reload your program, If you didn’t 
record it, then you'll have to type it all over again. That’s hard work, 
and life is hard enough as it is. 

Another final point concerns the number that you poke into 
$9629. If this is a small number, then the program works. Youcan't, 
however, poke a number greater than 255 into any single memory 
position. In addition, if the number that you place there amounts to 
more than 254 when it is multiplied by two, then the results of this 
program will appear very strange! That’s because a number greater 
than 255 cannot be stored in one memory byte. The routines that 
multiply numbers in your Oric/ Atmos are a lot more sophisticated 
than this simple example! 


Chapter Six 
Taking a Bigger Byte 


The simple programs that we looked at in Chapter 5 don’t do much, 
though they are useful as practice in the way that machine code 
programs are written. Practising assembly language writing and its 
entry into the Oric/ Atmos is essential at this stage, because you can 
more easily find out whether you are making a mistake when the 
programs are so simple. It’s not so easy to pick up a mistake ina long 
machine code program, particularly when you are still struggling to 
learn the language! 

Most beginners’ difficulties arise, oddly enough, because machine 
code is so simple, rather than because it is difficult. Because machine 
code is so simple, you need a large number of instruction steps to 
achieve anything useful, and when a program contains a large 
number of instruction steps, it’s more difficult to plan. The most 
difficult part of that planning is breaking down what you want to do 
into a set of steps that can be tackled by assembly language 
instructions. For this part of the planning, flowcharts are by far the 
most useful method of finding your way around. I never think that 
flowcharts are ideally suited for planning BASIC programs, but 
they really come into their own for planning machine code. 


Flowcharts 


Flowcharts are to programs as block diagrams are to hardware - 
they show what is to be done (or attempted) without going into any 
more detail than is needed. A flowchart consists of a set of shapes, 
with each shape being the symbol for some type of action. Figure 6. | 
shows some of the most important flowchart shapes for our purpose 
(taken from the standard set of flowchart shapes). These are the 
terminator (start or stop), the input/output, the process (or action) 
and the decision steps. Inside or beside the shapes, we can write brief 
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- START or END y PATH 
PROCESS PATHS JOIN 
DECISION INPUT or OUTPUT 


Fig. 6.1. The main flowchart shapes. 
notes of the action that we want, but once again without details. The 
purpose of these symbols is to give you a visual picture of what your 
program is intended to do. it need not show details ~ not at first, 
anyway — but it must show methods. 

Consider, for example, the flowchart in Fig. 6.2. This is the 
flowchart for a program which will read a byte from one address and 
write it to another. It’s a very simple piece of work, and that’s why 
I've used it as an example. The flowchart shows the steps, some 
names, and the direction of each step — but that’s all. There’s no 
mention of accumulators or of addressing methods. The flowchart is 
about whar you want to do, and the order in which things are done, 
not about the details of how you do it. The name ‘flowchart’ should 
also remind you of the very important point about direction of 


START 


READ BYTE 
FROM 
‘SOURCE’ 


WRITE BYTE 





Fig. 6.2. A flowchart for a program which will read a byte trom one address 
and store it at another. 
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‘flow’, showing how one step comes after another. What makes 
flowcharts important for machine code programmers is that it’s easy 
to forget what you want to do! Machine code is very much about fine 
details, and it’s easy to get so involved in the details that you forget 
what you are supposed to be doing. It’s rather like the guy who is 
doing a crossword, looks up a word in a dictionary, and gets so 
interested that he carries on reading the dictionary. The usefulness 
of the flowchart starts to come into its own when we start looking 
at loops — right now. 


The Power of the loop 


We can, if we like, divide programs into two kinds, ‘linear’ and 
‘looping’. A linear program starts, carries out each line of the 
program, then stops. A looping program, by contrast, will repeat 
some lines many times over until some condition is satisfied. As you 
know from programming in BASIC, the ability of the computer to 
carry out looping programs is one of its most important features. 

Very few machine code programs are linear, because the speed 
advantages of machine code are noticeable only when you use loops. 
In this chapter, then, we are going to look at several different types 
of loops, and how they are programmed. On the way, we shall learn 
a lot more about the action of the Oric/ Atmos system. We'll start 
with some simple ‘shifting loops’. 

A ‘shifting loop’ is one that shifts bytes from one set of memory 
addresses to another. Why should we want to do this? Well, as you 
will have seen earlier, it’s one way of shifting the position of an object 
on the screen. If we have an object which is represented by a set of 
bytes stored in screen memory, then shifting these bytes corresponds 
to shifting the object on the screen. We're not quite ready for that 
sort of programming yet, so we'll start small. The first problem, 
then, will be to move a set of bytes (a short BASIC program) from 
one set of addresses to another. 

Now, once again, we're not doing anything that could not be done 
(more easily) in BASIC. It’s the method that’s important, because 
the methods that you learn on simple examples are a guide to the 
methods that you have to use for more complicated examples where 
BASIC is not so useful. We'll start with a flowchart, which is in Fig. 
6.3. The flowchart shows that we pick two starting numbers. One of 
these, labelled START, is the address at which free memory starts 
when you first switch on, $950@. The other address, NEW, is a 
different value of $2099. What this flowchart is designed to do, then, 
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START 















READ FROM 
START + COUNT 





WRITE TO 
NEW + COUNT 





COUNT = 
COUNT + 1 





COUNT 
= NUMBER? 


Fig. 6.3. A flowchart for copying a set of bytes to a different set of addresses. 


is to copy a byte from $9590 to $2990, then from $9501 to $2001, 
from $0502 to $2002, and so on. The number of bytes has to be 
fixed. In this example, I have taken the figure of 209 (denary), $C8 
in hex, which is enough to copy the example program itself. 

The flowchart then shows what is to be done. A counter is set up, 
starting at zero. A byte is copied, and the counter is incremented. 
The addresses are also incremented. The counter is tested in a 
decision step. A decision step in a flowchart must have only two 
possible answers, YES or NO. This test is to see if the count has 
reached the value of ‘NUMBER’ (set at 290). If it has not, the loop is 
repeated, and bytes are copied until the count reaches 29. Now we 
have to find out how to make all this work using machine code. To 
start with, we shall plan to use indexed addressing. This neatly ties 


7O = Oric and Atmos Machine Code 


up the incrementing of the counter, and both of the addresses. If we 
use X-indexed addressing, then the count number can be held in 
register X. Each time we increment X, then an indexed load from 
SP EMO will, in fact, be from the address $PE9+X, and each store to 
$2300 will be to $2300+X. We can test for the end of the program by 
testing the value of the byte in register X. 





(a) 

Assembly language Code 
ORG $9600 
LDX #S90 A2 09 

LOOP: LDA S$9500.X BD 00 95 
STA $2000.X 9D 00 20 
INX E8 
CPX #209 E~ C8 
BNE LOOP DQ F5 
RTS 60) 





(b) 1@ HIMEM#9SFF : A=#9S66 

2@ FORN=8TQ12:READ DS 

3@ POKE A4+N, VAL ("#"4D#) : NEXT 

4@ CALL A 

1@@ DATA A2.,@,BD,@,5,9D,%,20,6£8,5E4,C8.D 

®,FS, 469 

Fig. 6.4. The copy program. (a) assembly language, (b) the BASIC poke 
program. 


Figure 6.4(a) shows an assembly language program which will 
carry out the action of the flowchart. Don’t run away with the idea 
that this is the only program which will carry out these actions. You 
could devise several programs that would carry out (or ‘implement’) 
the flowchart actions. Of these, one might be much faster in 
operation than the others. Another might require fewer bytes of 
code than any of the others. The testing for a value in X, for 
example, would be much easier if you started with a number in the X 
register and decremented the register. There’s seldom any single 
‘perfect’ solution to a problem, so don’t take the sample programs in 
this book as being anything more than aids to learning. The perfect 
program, as far as you are concerned, is one that does exactly what 
you want it to do. 

Now examine the program in detail. It starts as usual with a 
reminder of the address at which the code is to be located, $9609. 
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The next step is to load zero into the X register, using an immediate 
loading. The third line, however, introduces a new idea, a label. A 
label is a word that represents a byte or an address, just as a variable 
name represents a number. A label is attached to a place in an 
assembly language program, by using the label name ahead of the 
opcode, separated by a colon. Its meaning is, quite simply, ‘this 
address’. The label LOOP in this line means the address that is 
stored in the Program Counter at the instant when this line is carried 
out. We know what this address must be, because if the LDX 
instruction byte is a $960, the LOOP label must be at address 
$9602. In assembly language, however, it’s a lot more convenient to 
mark the instruction witha label than to have to work out addresses. 
If you use an assembler, the action of typing a label will ensure that 
the address is memorised and used. 

Now for the action. The next line gets a byte from the starting 
address. With the X-register storing zero, the load will be from 
address $0509. This byte is then stored by the next command at 
address $200(, again because the value of the byte in X is zero. The 
X register is then incremented. On the first pass through this loop, 
this makes the byte in X equal to |. The CPX #299 step then tests 
this number, to see if it is equal to 209. If it is not equal, the BNE 
(branch if not equal to zero) command causes the program to loop 
back. By using the label word ‘LOOP’ following BNE, you ensure 
that the program shows where you must loop back to. When, 
eventually, the number stored in the X register reaches 200, the BNE 
test fails, there is no loop back, and the RTS is carried out. The effect 
of the complete program is to copy a block of 200 bytes which start 
at $9500. to another block of addresses starting at $2000. 

Now try it out, using the BASIC POKE program in Fig. 6.4(b). 
Note that what follows the BNE instruction byte of $D@ is a 
‘displacement’ byte of $F5. This is the negative number which, when 
it is added to the address number in the program counter, will get 
back to the address number of the LDA START,X command. 
Because the PC register automatically increments after each byte is 
read, this negative number Is one step more negative than you might 
expect from subtracting addresses. Figure 6.5 shows how these 
displacements have to be calculated. If you use an assembler, then 
the system of using label words ensures automatically that the 
displacement bytes are always correctly calculated — if they can be. 
The catch is that you can’t use relative addressing fora displacement 
of more than 127 forward or 128 back. If you try, the assembler will 
stop and issue an error message. Without an assembler, you have to 
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check and double-check each displacement byte very carefully. Ifa 
program goes berserk, it’s almost always because of a faulty 
displacement byte. 

When the program of Fig. 6.4(b) runs, you don’t see much 





Destination: the address that you want to jump to. This will have a label 
name ahead of it in the assembly language line. 

Source: the address that you want to jump from, the address of the 
instruction which has the label name following it. 

Displacement: the byte equal to destination minus source minus 2, put into 
hex form. 


Example: 
9620 173 
9621 4) 
9622 2 
9623 240 


9624 displacement byte 


The ‘source’ address is 9623, where the BEQ byte is placed. The ‘destina- 
tion’ address is 9620, the LDA command. 

The procedure is: 

Destination address — source address = 9629 — 9623 = —3 

Now subtract another 2. so that —3-2=—S. 

In denary, the equivalent byte for —5 is 256-5 = 251. This must be the 
byte at address 9624. In hex, this displacement is $FB. 


How to check displacement bytes: 

Positive (forward) jump. Count the number of bytes from the next 
instruction to the byte just before the destination. This should be equal to 
the displacement byte. 

Negative (backward) jump. Count the displacement byte itself as FF. 
Count back, FE, FD, FC ... as you go each step back. The number you 
have reached when you get to the correct label name is the value of the 
displacement byte. 


Fig. 6.5. Finding the size of a displacement byte, and checking the 
displacement. 


evidence of it. If, however, you carry out DOK E#A9,#20@1, which 
shifts the start of BASIC to address 2091, you'll find when you LIST 
that you have a program at this address. You can go back to the 
original program by using DOKE#A9,#5@1. If you NEW this 
program, you will find that the copy still exists at #2091 (use 
DOK E#A9,#2901 again to check). You cannot RUN the copy. 
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however, because the addresses for the line numbers following line 
I) are wrong. 

Just at this stage, incidentally, it’s interesting to look at what 
NEW does. If you read the first ten bytes of a BASIC program 
before you NEW it, and then again after, you'll find that NEW 
affects only the first two. These first two are set to 9, which is the way 
that the Oric/Atmos marks the end of a program. To restore a 
program after NEW, then, you need only restore these first two 
numbers. We'll look at this point again later. 


Count your loops 


It's time now to takea look at another type of loop, called a counting 
loop. The importance of this one is twofold - it’s the way that we 
program a time-delay in machine code, and it also gives me an 
excellent opportunity to demonstrate just how fast machine code 
can be. 

The type of loop that you use most in BASIC is the FOR...NEXT 
loop. This uses a ‘counter’ variable to keep a score of how many 
times you have used the loop, and compares the value of the counter 
with the limit number that you have set each time the loop returns. 
Now the action of a FOR...NEXT loop can be simulated in BASIC 
without using FOR or NEXT, and one method is shown in Fig. 6.6. 


1@ C=@:ND=18 

26 PRINT"ACTION "iC 
3@ C=C+i 

4@ IF CC=ND THEN 20 
38 PRINT "FINISHED" 


Fig. 6.6. A simulated FOR...NEXT loop This uses methods that are very 
similar to the methods we have to use in machine code. 

The count number is C, and its limit is ND. At the end of the 
program, the value of C will be 11, just like the value of the counter 
ina FOR N= | TO 19 type of loop. The next thing, then, is to take a 
look at the flowchart for this type of program, and that’s shown in 
Pig, 6.7; 

This method of forming a counting loop is the one that we use in 
machine code. We can write some assembly language that will do the 
same job — but, as usual, we have to give a lot more thought to how 
the task will be done. For one thing, we don’t have variable names in 
machine code. We have to decide where we shall store a number, and 
in what register we shall carry out the task of decrementing it. The 
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decision step is easier - we can use a BNE test this time to keep the 
program looping back until the content of the register that we have 
tested is zero. In case you're wondering how we specify which 
register we're testing, the answer is that it’s always the one that we 


used just before the BNE (or any other) test. 


START 


COUNT=@ 


DO PRINT 
ACTION 
COUNT = 

COUNT +1 












Fig. 6.7. A flowchart for a counting loop. 





(a) 





Assembly language Code 
ORG $9600 —— 
LDX #$FF A2 FF 
LOOP: DEX CA 
BNE LOOP D# FD 


RTS 69 
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(b) HIMEM#9OSFF : A=#9600 
FORN=@TOQS: READ D¢ 
POKEA+N, VAL ("#"+DS) s NEXT 
PRINT"START": CALLA: PRINT"STOP” 
a@ DATAA2, FF.CA, DG, FL, &@ 


_ - Ned bd font 
9°95 9 3 9 


Fig. 6. 8. (a) The assembly language and (b) the BASIC poke program for a 
counting loop. 


Figure 6.8(a) shows what we end up withas an assembly language 
program. The register that we use is the X register, rather than the 
accumulator. This is because the X-register (along with the Y one) is 
better adapted for counting operations. What makes it better 
adapted is the presence of increment and decrement commands. 
INX and DEX will, respectively, increment or decrement the X 
register. The commands INY and DEY will perform the same 
Operations on the Y register. There is no corresponding pair of 
commands for the accumulator, and if we want to carry out 
counting operations using the accumulator, we have to go about 
them ina slightly different way. In this example, then, the X-register 
is loaded with $FF, which is 255 in denary. This is the largest number 
that we can load into an eight-bit register. Having loaded the 
accumulator, we then decrement it, and mark this address as 
‘LOOP’, the place we want to return to if the register content is not 
zero. The test is carried out by BNE, branch if not equal to zero, 
because we want the program to repeat the decrementing action 
until the contents of the X register reach zero. 

In the BASIC poke version in Fig. 6.8(b), the machine code is 
called in line 49. Now when you run this one, you will not see much 
of a time delay between the printing of ‘START’ and the printing of 
‘STOP’. This isn’t because nothing has happened, it is because the 
machine code count-down is so fast! Figure 6.9 shows a BASIC 


1@ C=@:ND=14 

2@ PRINT"ACTION "5C 
3@ C=C+1 

4@ IF C<=ND THEN 20 
0@ PRINT"FINISHED" 


Fig. 6.9. A BASIC version of the machine code counting program. 


version of this count-down, using the same number, and you can see 
that there is a noticeable pause. The difference does not reflect the 
comparative speeds, however, because quite a lot of time is spent in 
the printing actions of the BASIC part of each program. To see just 
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how great the advantage of machine code can be in terms of speed, 
we need to work with much larger numbers. Now there are several 
ways of doing this, but one which we can look at right now involves 
two loops. 

You have probably met nested loops in BASIC. The principle is 
that there is an inner loop and an outer loop. On each pass of the 
outer loop, the whole of the inner loop is carried out. This allows us 
to create much longer time delays, by doing one count inside 
another. Suppose we had, in BASIC, the lines: 


19 X=255:PRINT“START” 
29 X=X-I 

39 Y=255 

49 Y=Y-] 

59 IF Y<>$ THEN 49 

69 IF X<>$ THEN 20 

70 PRINT“STOP” 


then these would carry out a count-down of Y from 255 to 9 each 
time the value of X was decremented. Try this one — and timeit. You 
won't need a stop-watch - anything with a minute hand will do! 
For acontrast, let’s see how the same numbers could be dealt with 
in a machine code count-down. Figure 6.10(a) shows the assembly 


a eee 








Assembly language Code 
ORG $9609 —_— 
LDX #$FF A2 FF 
LOOP2: LDY #SFF Ag FF 
LOOPI: DEY 88 
BNE LOOP I D~? FD 
DEX CA 
BNE LOOP2 D F8 
RTS 69 
(b) 1@ HIMEM#9SFF: A=#9400 
29 FOR N=@TO1G@:READ DS 
=@ PORE AtN, VAL C"#"4D$) :NEXT 
49 PRINT"START": CALL ASFRINT"STOF" 
194 DATA A2.FF,46,FF,28,D0,FD,CA,De,Fa, 
6a 


Fig. 6.10. A nested loop counting program. This takes considerably longer to 
execute. 
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language version. The X-register is loaded with $FF, and the Y- 
register also with $FF. This second instruction is labelled ‘LOOP2’. 
Then comes DEY, so that the Y-register is decremented, and this is 
labelled ‘LOOP 1’. The BNE test then returns to this LOOP! point 
(the inner loop) until the Y register has reached 9. After that, the X 
register is decremented, and then tested. Note that the order is not 
quite the same as in the BASIC version. In a machine code 
decrement and test action, you must have the decrement done just 
before the test, otherwise the register that is tested may not be the 
correct one. If the X register has not reached zero, the program loops 
back, this time to Loop2, to fill up the Y-register again and perform 
the ‘inner loop’ yet again. 

When you try this, it’s still almost too fast to follow! It’s a good 
illustration of the speed advantage of machine code as compared to 
BASIC. Just compare the speeds of the two counts. The machine 
code causes a slight delay. The BASIC version ... well, it gives you 
time for a coffee. For speed — use machine code. 


Accumulator INC and DEC 


I pointed out earlier that there are no INC and DEC commands for 
the accumulator. This does not, however, mean that we can’t use the 
accumulator for counting operations, just that it’s not so well 
equipped as the X- and Y-registers. Supposing we have to carry outa 
count in the accumulator, however, we can make use of SBC #1, 
meaning subtract | from the content of the accumulator. This would 
lead us to a count-down program of the sort that is shown in Fig. 
6.11. We start by using SEC, the command which sets the carry bit. 


(a) 





Assembly language Code 
ORG $9600 —— 
SEC 38 
LDA #$FF A9 FF 
LOOP: SBC #1 E9 gj 
BNE LOOP DQ FC 


RTS 60 
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(b) 10 HIMEM#95FF :s A=#9600 
2@ FOR N=@TO7:READ Dt 
3@ POKE A+N, VAL ("#"+D%) : NEXT 
4@ PRINT"START":CALL A:PRINT"STOP” 
10@@ DATAZ8,A9,FF,E9,1,D0,FC, 60 


Fig. 6.11. (a) The assembly language version of the program and (b) the BASIC 
poke program. 


This is needed, because if the carry bit happens to be clear, then the 
first SBC action will subtract 2rather than |. All the remaining SBC 
actions will be normal, and it would not make much difference toa 
time delay like this to have an extra decrement. In some kinds of 
decrement action, however, like counting bytes, the subtraction of 2 
instead of | could be a disaster. For this reason, it’s a good habit to 
set the carry bit before you carry out a subtraction of this sort. The 
SBC #1 is the decrementing step, and the loop runs pretty much like 
the X register loop that we looked at earlier. 

The 6502 does not confine you to decrementing numbers that are 
stored in the registers, however. The DEC action can be applied to 
any address in memory, so you can write count-down programs that 
use as many bytes as you like. The most convenient addresses to use 
for storing counting bytes are the zero page addresses (from to 
255), but when your 6502 is installed in an Oric/ Atmos, you have to 
be careful! This is because the Oric/ Atmos uses several of the zero 
page addresses for its own purposes, and placing bytes in some of 


(a) 

Assembly language Code 
ORGS/96)0 an a 
CLC 38 
LDA #$FF A9 FF 
STA 379 85 79 

LOOPI: STA $71 85 71 

LOOP2: STA $72 Bo 22 

LOOP3: DEC $72 C6 72 
BNE LOOP3 Dé FC 
DEC $71 C6 71 
BNE LOOP2 D@ F6 
DEC $70 C6 76 
BNE LOOP] D@ FO 


RTS 6p 
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(b) 1@ HIMEM#95FF: A=#96e0 
2@ FORN=@T021:READ Ds 
3@ POKEA+N, VAL ("#"+D$) = NEXT 
4@ PRINT"START": CALLA: PRINT"STOP" 
10@ DATAZ8,A9,FF.85, 70,85, 71,85, 72,C6,7 
2,D@,FC,Cé, 71, D0, F6, C4, 74, DO, FG, 60 


Fig. 6.172. Acounting program that makes use of three bytes, all stored in zero 
page memory. (a) The assembly language program and (b) the BASIC poke 
program. 


these addresses will cause havoc to the operation of the machine. A 
quick inspection of the memory shows that addresses $79 to $73 are 
often free, so perhaps we could make use of these for a really large 
count. Figure 6.12 shows the assembly language for this action. The 
three addresses which I have used are $79, $71, and $72. The 
program starts by loading $FF into the accumulator, and then 
storing this number in all three zero page addresses. Because these 
are zero page addresses, we can make use of the fast and simple 
system of zero page addressing. The program makes no other use of 
the accumulator, so that the number $FF will remain in the 
accumulator throughout. This allows us to store the accumulator in 
each memory address without reloading the accumulator. 

The technique for the count-down is very much the same as 
before, except that there are three loops. You might try drawing a 
flowchart for yourself to see how these are arranged. The effect is 
that we are counting down the number 16777215 (denary) to zero. 
As you might expect, this takes a lot longer than a two-register 
count-down ~ several minutes. If you use a stop-watch to measure 
the time between the START and STOP messages, and divide this 
by the number shown above, you'll get some idea of how long (on 
average) each loop takes. Don’t try to count-down this number ina 
BASIC program - life’s too short! 


Subroutine selection 


We have looked at two types of loops in machine code, but 
completely neglected a third. A holding loop is one which keeps 
repeating a group of actions until some condition is satisfied. 
Suppose that you want a machine code program that takes the 
ASCII code for a key that has been pressed, and prints on to the 
screen the character corresponding to that key. A flowchart for this 
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action is shown in Fig. 6.13. The first terminator is ‘START, 
because every program or piece of program has to start somewhere. 
The arrowed line shows that this leads to the first ‘action’ block, 
which is labelled ‘get character in A’. This describes what we want to 
do - get the code number for a character in the accumulator. The 
character may be zero, because no key has been pressed. This is 
where the holding loop comes in. The accumulator Is tested, and if 
the byte in the accumulator is zero, the program loops back to the 
start. We don’t know how we're going to do this at present — that 
comes later. After getting the character, the arrow points to the next 


Get character 
inA 


No 










Store in screen 
memory 


Fig. 6.13. The flowchart for a ‘holding loop’ action. 
action, storing the byte in screen memory. That’s how we carry out 
the ‘print’ part of the action, and it’s something that we’ve looked at 
earlier. The END terminator then reminds us that this is the end of 
this piece of program; it’s not an endless loop. 

This is a very simple flowchart, but it neatly illustrates a holding 
loop action. Getting a character into the accumulator implies that 
the keyboard must be activated, looking for a key being pressed. Ifa 
key is not pressed, the keyboard must be checked again, over and 
over again. The next thing that we need to do is to find how we geta 
character into the accumulator from pressing a key. Routines of this 
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sort already exist in the RAM of the Oric/ Atmos, and we can use 
them. The same applies to placing a character on the screen. 
Converting each ASCII code number from the keyboard into the 
eight bytes that would produce the correct shape on the screen 
would be a considerable task. Once again, however, the routines 
already exist, and it would be pointless to write them all over again 
unless we wanted something really different. 

Now a lot of computer manufacturers regard their ROM 
subroutines as a matter of secrecy. They discourage you from 
learning about them, and do not publish details of the subroutine 
addresses and how they should be used. Oric take the opposite 
attitude. The Oric/Atmos manual contains some useful details 
about the most useful ROM subroutines and how they should be 
used correctly. This way, Oric hope to encourage you to write 
machine code programs that will work well, and which will still work 
even if changes are made in the ROM at some later date. In addition, 
some subroutines are written so that you can ‘break into’ them - but 
more of that later. 


The use of JSR 


JSR is one of the 6502 mnemonics, which means ‘jump to 
subroutine’. When the microprocessor comes across a JSR code, it 
will read the following two bytes as an address, place this address in 
the program counter, and start to execute the code at this new 
address. That’s not quite all, though. Before the new address is 
placed in the PC, the old address (the address of the next instruction 
following the JSR) is stored temporarily. The idea is that JSR will 
cause a piece of code to be run, but at the end of that piece of code, an 
RTS instruction byte will cause the 6502 to return to the old address, 
carrying on as if the JSR had not been there. Sounds familiar? Of 
course it does, because it’s the same as the GOS UB action in BASIC. 
JSR and RTS are to 6502 machine code as GOSUBand RETURN 
are to BASIC. The point about all the ROM routines that Oric tell 
you about is that each one ends withan RTS. If you call any of them 
into action with a JSR, then, you will find that your program goes 
on normally after the subroutine has been used. What you need to 
know, however, is what each subroutine does and what effect it has 
on the registers of the 6502. We'll start this quest by looking at two of 
the most useful subroutines, GTORKB and VDU. 

No, these aren’t misprints, just abbreviations. GTORKB means 
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‘get a character from the keyboard’. The effect of the routine, then, is 
to read a character from the keyboard, rather like the action of 
KEYS in BASIC. It carries out the flowchart action of the first part 
of Fig. 6.13, and needs to be followed by a holding loop. Figure 6.14 
shows the assembly language version of the flowchart, with the 
address $EB78 used for GTORKB, and address $F77C for VDU. 
There are two points that we have to watch carefully, though. The 
first one is that the Oric-I uses different addresses, $C5F8 for 
GTORKB and $CB61 for VDU. Secondly, the keyboard routine 
gets the characters as an ASCII code in the accumulator, but the 


(a) 





Assembly language Code 
ORG $9600 

LOOP: JSR $EB78 20 78 EB 
BEQ LOOP Ff FB 
TAX AA 
JSR $F77C 29 7C F7 
RTS 66 


(b) 1@ HIMEM#9SFF : A=#9600 

2@ FORN=@TO9:READ Ds 

3@ POKEAtN, VAL ("#"+4+D%) =NEXT 

4@ CLS:CALLA 

19@ DATA2@, 78, ER, FO, FB, AA, 2@, 7C,F7,60 
Fig. 6.14. The ‘print a character’ program (a) in assembly language and(b) asa 
set of POKEs. 
screen printing routine needs the character as an ASCII code in the 
X register! How do I know that? The Atmos manual illustrates the 
use of these routines in Appendix 9. This is the sort of information 
that you ust have if you are to use machine code. In the program, 
then, we must copy the byte in the accumulator into the X register. 
This is done by the TAX command (transfer A to X). The programis 
then delightfully simple - a call to GTORKB, the test for zero and 
loopback, a TAX, then a call to VDU and that’s all! When this runs, 
pressing a key will cause a letter or other character to appear at the 
cursor position. This doesn’t look any different from what happens 
when you press a key at any other time, so how do we know that this 
program works? Easy - just run it, and press a letter key. The letter 
will appear on the screen, with the READY prompt underneath it. 
Now press the RETURN key. The cursor simply moves down to the 
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next line. There’s no‘SYNTAX ERROR’ message, as you would get 
if you simply typed a letter and then pressed RETURN. The 
‘SYNTAX ERROR?’ is missing because we have short-circuited the 
routine. We’ve broken a lot of new ground in this short piece of 
program, so perhaps this is a good time to go over it all carefully and 
make sure that you know what it has all been about before we plunge 
rather deeper into the business. 


Testing your character 


One thing that can be a bother here, as | have indicated, is that the 
Oric-1 may not use the same address. Several of the ROM addresses 
in the Atmos have changed as compared to the older Oric-1. The 
way round this is to use address $$23B for both the Oric-I and the 
Atmos in place of $EB78. This address, $923B, is only a sort of 
‘staging post’. It directs the subroutine to another part of memory, 
where there is more room. The point of using it is that $$23B is in 
RAM, and its contents can be altered. It’s likely that if your machine 
does not keep its keyboard routine at $EB78, then the correct 
address will be kept at $$23B. If you use JSR $023B in place of 
$EB78 then your program should still work. The screen print 
routine is similarly treated, with its address obtained by JSR $9238. 
Addresses $9238 to $§249 are used in this way. If you are using the 
Atmos, you can use the main ROM addresses that I have detailed 
here. 

Meantime, back to the read and write routines. We can expand 
the idea that the program of Fig. 6.14 introduced. This time, we'll 
make the process repeat until the RETURN key is pressed. When 
the RETURN key is pressed, the ASCII code $§D (denary 13) is 
placed in the accumulator by the GTORKB routine. What we have 
to do is test for this character, and jump out of the loop when it 
appears. Figure 6.15 shows the flowchart for this suggested 
program. 

The complete program is illustrated in Fig. 6.16. The character 
which GTORKB has placed in the accumulator is compared with 
$$D. The CMP step, remember, does no? alter the size of the byte in 
the accumulator, but it will cause flags to be changed in the P (status) 
register. If the RETURN key has been pressed, the accumulator will 
contain the byte $9D, and the CMP action will set the zero flag. If 
the zero flag is set, then the effect of BEQ OUT will be to make the 
program jump to the label word ‘OUT’. Ifthe RETURN key was nor 
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Get character 
inA 






Store in screen 
memory 





Fig. 6.15. A flowchart for a repeated character printing program. In this case, 
characters are printed until the RETURN key is pressed. 





(a) 





Assembly language Code 
I a a cn ee: © al ene Oe, 
ORG $9696 
LOOP: JSR SEB78 20 78 EB 
BEQ LOOP FQ@ FB 
CMP #S89D C9 9D 
BEQ OUT FO 07 
TAX AA 
JSR $F77C 2 7C F7 
JMP LOOP 4C 00 96 


OUT: RTS 60 
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(b) 1@ HIMEM#95FF: A=#960e 
2@ FORN=0T016:READ D$ 
3@ POKEA+N, VAL ("#"+D%) : NEXT 
4@ CLS:CALLA 
19@ DATAZ@, 78,EB,FO,FB,C9, OD, FO,7,AA, 20 
> 7C,F7, 4C, 00, 96, 6@ 


Fig. 6.16. (a) The assembly language and (b) the POKE program for the 
character printing process. 


pressed, then the jump is ignored; the JSR $F77C prints the 
character, then the JMP $9609 returns to the keyboard scanning 
routine. 

From then on it’s plain sailing. When the routine assembles, you 
can press keys to your heart's content, and see the result on the 
screen. You can then return to BASIC by pressing the RETURN 
key. What keys work? All the letter and number keys, including the 
DELETE, will have their normal effect. The arrowed keys will also 
allow the cursor to shift in the usual way. The CTRL key used witha 
letter key can have some odd consequences, however. Some CTRL 
sequences can cause the program to lock up, and you'll have to press 
the button under the computer to recover your program. 

Meantime, what about trying some variations. What happens, for 
example, if the RETURN key is tested for after its code has been 
‘printed’ by VDU? You will have to shift the CMP #30D and BEQ 
OUT steps so that they follow JSR F77C. Try it - can you explain 
what happens? It’s just as if you had typed some letters at random, 
and then pressed RETURN. Not enough? Then try this - add 
between GTORKB and VDU the steps CLC and ADC #1. You will 
have to be careful about where you place CMP #9D now. If CMP 
#9D comes before the new steps, you can leave it alone. Ifit follows, 
then it will have to be changed to CMP #E. Try it, and you'll see 
why. Ever wanted to get into the message coding business? 


Chapter Seven 
Ins and Outs and 
Roundabouts 


Video loops 


Of all the loop programs that we can make use of in machine code, 
loops that involve the video display addresses are among the most 
useful. We have seen earlier that we can make things happen on the 
video display by making use of POKE commands from BASIC. The 
techniques that you used for POKE displays on the screen can also 
be used for machine code, and the main differences are that machine 
code is faster and involves more work on your part! 

Take a look, for starters, at Fig. 7.1. This shows the flowchart for 
a program that will fill part of the text screen with one character. The 
idea is that we load a register (the accumulator is usually the best bet) 
with a code number for a character, and we store this at the first 
screen address, which is $BBA8. We must then increment this 
address, store the accumulator again, and repeat this process for as 
long as we need to, until we reach the last address. The flowchart 
shows what we have to do, but you need to know howto carry It out 
with the 6502. This is the kind of program which can make use of 
indexed addressing, so we'll start by recalling what this involves. 

There are two index registers, X and Y, each of which can storea 
single byte number. When we carry out an indexed load or store (or 
any other operation that copies a byte from memory), the number 
that is held in the index register is added to the address that we have 
specified. This forms a new address, and it’s this address that is used 
for the load or store. If, for example, we have 2 stored in the X 
register, and we specify a store as: 


STA $BBA8,X 


(hex numbers), then this means that the address which will be used Is 
$BBA8+ 2=$BBAA, and the byte in the accumulator will be stored 
to address $BBAA. One of the features that makes this so useful is 


Ins and Outs and Roundabouts 87 












START 


LOAD IN 
CHAR 


COUNT=@ 





WRITE CHAR, 
MOVE CURSOR 





COUNT = 
COUNT + 1 


Note: Actual test 
is for Count=@ 


Fig 7.1. A flowchart for filling part of the screen with a character. 


that we have INX and DEX commands which will, respectively, 
increment or decrement the number that is held in the X index 
register. There are corresponding INY and DEY commands for the 
Y index register. 

Let’s get down to the assembly language version, which is shown, 
along with the BASIC program, in Fig. 7.2. The first step is 
straightforward — load the accumulator with $26. This is the ASCII 
code number that will produce the ‘ampersand' sign, &. Obviously, 
you could try any other code number that you liked to use. We then 
load the X register with zero. The next item is the loop. We start the 
loop by storing the byte in the accumulator to the address given by 
$BBA8 (hex) plus the byte in the X register, and then incrementing 
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(a) 


LDA #$26 :ASCII ‘&’ 
LDX #$00 

LOOP: STA $BBA8,X ;put on screen 
INX snext address 
BNE LOOP ;do next one 
RTS :back to BASIC 





(b) 1@ HIMEM#95FF: A=#9600 
2@ FORN=@T010:READ D¢& 
3@ POKEA+N, VAL ("#"+D$) =: NEXT 
4@ CLS:CALLA 
10@ DATAAI, 26, A2,, 9D, AS, BB, E8, D@, FA, 60 


Fig. 7.2. (a) The assembly language program. (N.B. The code has not been 
shown this time because the assembly language is more important.) (b) 
BASIC poke program. This version, however, fills only the top part of the 
screen. 


the X register. In assembly language, these steps are written as: 


STA SBBA8,X 
INX 

The next step is to compare the content of the X register with zero, 
using BNE. Since the X register started at zero, and has just been 
incremented to I, the comparison will not give zero, and so BNE will 
cause a loop back to store the character at another address. When 
the number in the X register is equal to SFF (255 denary), then the 
next increment action will make the content of the X register equal 
to zero again. This is because the register can hold only one byte. At 
this point, the BNE test fails, and the program breaks out of the 
loop, and returns to BASIC. 

Now this does some of what we want, but not quite all. It will place 
a character in 256 screen addresses, but the text screen consists of 
1080 addresses. What has limited us in this case is the size of the X 
register - one byte. This makes certain that an indexed load or store, 
carried out in a loop, cannot deal with more than 256 bytes. 
Working on the basis that half a loaf (or quarter of a screen) is better 
than nothing, we'll try it out. Later on, we'll see how we can get 
round this limitation. 

Transforming this assembly language by hand into machine code 
is reasonably straightforward. Once the machine code bytes have 
been written down (check the displacement byte that follows the 
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BNE), then the BASIC program that pokes the bytes into memory 
can be written down (Fig. 7.2(b)). It shouldn't take long - apart from 
the value of N and the DATA line, it’s almost the same as any of the 
other programs so far. At the end of the run, we must use the STOP 
and RESTORE keys to return the screen conditions to normal. 
When this runs, there is a short delay while the slow BASIC pokes 
the numbers into the memory, and then the machine code does its 
stuff in its usual lightning way. 


The rest of the way 


Writing a program that will fill all of the screen is not quite so easy, 
because of the limitation of the size of the index register. There are 
several ways of carrying out the action that we need, but the most 
straightforward method makes use of what is called indirect 
addressing. This was briefly mentioned in Chapter 4, and now that 
we're up against it, we'll have to take a closer look at one of the two 
methods that the 6502 can use. The two indirect addressing methods 
of the 6502 are often known as ‘indexed indirect’ and ‘indirect 
indexed’. Titles like these are rather confusing, so in this book, I'll 
stick to the simpler descriptions of ‘X-indirect’ and ‘Y-indirect’. This 
is because one method makes use of the X-index register, and the 
other method makes use of the Y-index register. The one we need for 
the loop program is the Y-indirect method. 

The way that Y-indirect addressing operates is as follows. The 
first address that we want to use, such as $BBA8 in our example, is 
stored as two bytes in two consecutive zero page addresses in 
memory. As always, the bytes are stored in the low-then-high order, 
and they sus be in zero page memory. A number is also placed in 
the Y index register. Now when we carry out a memory operation 
such as a load or a store, we use the Y-indirect form. In assembly 
language, a Y-indirect store would be written in the form: 


STA (address), Y 


Its effect is fairly complicated at first sight. The low-byte of the 
address is copied from the memory, and the content of the Y-register 
is added to it. If there is any carry from this addition, it is added to 
the high-byte. The two new bytes of address are then used for the 
store (in this example) operation. Suppose, for example, that we 
stored the first screen address of $BBA8 in zero page memory, using 
hex addresses $25 and $26. Using the low-high order of storing 
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means that address $25 will store $A8 and $26 will store $BB. Nowif 
we have the number $26 (hex) stored in the Y register, then the effect 
of: 


STA ($25), Y 


will be to add $29 to the number stored in $25 (which was A8), and 
so form the number $C8. The upper part of the address then comes 
from $26, giving the complete address as $BBC8. This is the address 
to which the byte in the accumulator will be copied. 


(a) 
LDY #SA8 ;add to screen address 
LDA #369 ;screen start low byte 
STA $25 store at $25 
LDA #$BB screen start high byte 
STA $26 store at $26 
LDA #$2A sload character & 
LOOP: STA ($25), Y store at screen address 
INY sincrement address 
CPY #$DF sis it low byte of end? 
BEQ TEST ;check high byte if so 
CPY #306 scheck need to increment high byte 
BEQ BUMP ido it if needed 
BNE LOOP ;otherwise back and repeat 
TEST: LDX $26 sget high byte 
CPX #SBF ;compare high byte, last address 
BNE LOOP sback if not 
RTS out if so 
BUMP: INC $26 increment high byte 
BNE LOOP ;back to loop 
RTS ;out if anything goes wrong 





(b) 10 HIMEM#95FF: A=#9600 

2@ FORN=@TOS6:READ Dt 

3@ POKEA+N, VAL ("#"+D$) s NEXT 

4@ CLS:CALLA 

10@ DATAAG, AS, AI, @, 85, 25, A9, BB, 85, 26, 
AI, 2A, 91, 25,C8, CO, DF,FO,6 

11@ DATAC@, 4,F@,9,D@,F3, AS, 26,E@, BF,D 
@, ED, 60, E64, 26, D@,E8, 6@ 


Fig. 7.3. Filling the entire screen. (a) Assembly language. (The hex codes are 
not shown now, so that you can concentrate on the assembly language.) (b) 
BASIC poke version. 
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Figure 7.3(a) shows the complete assembly language version of 
the program. The first six steps place the correct values into the 
registers and into memory. This has not been done in the most 
efficient way, but at least it’s easy to follow. Where things start to get 
more difficult is step 7, at the start of the loop. What causes the 
problem is the need to carry out the incrementing of the screen 
address for 1079 times. We’ll take a look at this part of the program 
in close detail. 

At the start of the loop, the number in the Y register is $A8, and 
the ‘base address’ for the STA operation is stored in zero page 
addresses $25 and $26 (hex). The address $25 stores $ and address 
$26 stores $BB, so that the two bytes, plus the byte in the Y register, 
make up the first screen address of $BBA8, denary 48949. When the 
STA ($25),Y step is used for the first time, then, the byte in the 
accumulator will be put into address $BBA8. The INY step then 
increments the number in the Y register from $A8 to $A9. Two 
comparison steps then follow. The first one compares the contents 
of the Y register with $DF. This is because the last screen address is 
SBFDF. We don’t want to stop the loop just because the Y register 
holds $DF, though, only when the address $26 happens to be storing 
SBF at the same time. The BEQ TEST stage, then, jumps to a piece 
of program that will test the number in address $26 to find if we have 
reached the end of the screen. If we haven’t, then the BNE LOOP at 
the end of the TEST routine will get back to the loop. 

There’s another test, however. Because an address can hold only 
one byte, we have to look for the Y register counting past $FF to $0. 
When this happens, we must increment the upper part of the 
address, so that the address which follows $BBFF is $BCQ9 rather 
than $BB@@. This is done by the second check, CPY S#09. If the Y 
register contains zero, then the program goes off to the BUMP 
routine. This simply increments address $26, and then goes back to 
the loop. The return to the loop could have been donc by using JMP, 
with a full address, but it’s more convenient to use BNE. The content 
of $26 should never get to zero in the course of the program, so 
the jump is really unconditional. Just in case of mishaps, though, I 
have followed it with the RTS. That’s called defensive program- 
ming. Fig. 7.3(b) shows the BASIC poke program which places the 
bytes in memory, and runs the machine code. 
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Take character 
from memory 


Restore 
first 
character 


Increment character 
number and screen 
address 


Last screen 
address? 


a a A flowchart for printing the entire character set, ASCII codes $26 
to : 


Take a bigger cast-list 


We can modify the program of Fig. 7.3 in an interesting way. 
Suppose we started with the accumulator containing $2, and we 
incremented the accumulator on each pass through the loop. This 
would mean that we would produce on the screen each character for 
the numbers $20 to $FF (255 denary). What would happen then? 
Well, since the accumulator can hold only eight bits, and $FF is the 
largest number it can hold, it simply goes back to 9 next time it is 
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incremented. We don’t really want to place some of these numbers in 
the screen memory, however. The numbers below $26 will cause 
colour (and other) effects, the numbers above $7E (127) will give 
some similar effects. To obtain a display of all the normal characters 
of the Oric/Atmos, then, we should restrict the numbers in the 
accumulator to the range $29 to $7E. Figure 7.4 shows the flowchart 
for this action, and Fig. 7.5 shows the assembly language and the 
BASIC poke program. There’s quite a lot in this program, and it’s 
about as long a machine code program as | would care to write 
without the aid of an assembler. Let’s look at it in detail. 

The first seven steps are concerned with loading registers and 





LDY #SA8 sIsb start 
LDA #S0@ sIsb base address 
STA $05 ;put into page 9 
LDA #$BB :msb start 
STA $06 -page @ 
LDA #5329 ‘first character 
STA $07 :put in page 9) 
LOOP: LDA $47 sget character 
STA ($95), Y sindirect store 
CMP #S7E sis it last character? 
BEQ RSTOR srestore $20 if so 
INC $07 :pick next character 
NXT: INY snext address 
CPY #SDF check for end 
BEQ TEST with subroutine 
CTN: CPY #300 new high byte needed? 
BEQ BUMP sif so. do it 
BACK: BNE LOOP :repeat actions 
TEST: LDX $06 stake high byte 
CPX #$BF ‘end of screen? 
BNE CTN sback if not 
RTS : out if it is 
BUMP: INC $06 znew high byte 
BNE BACK :back to main loop 
RTS :just in case 
RSTOR: LDA #820 ‘start again 
STA $7 sback in page 0) 
BNE NXT sback to main loop 
RTS sjust in case 





(Fig. 7.5(a)) 
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(b) 1@ HIMEM#9SFF: A=#9600 

2@ FORN=@TOS3:READ DS 

3@ POKEA+N, VAL ("#"+D%) : NEXT 

4@ CLS:CALLA 

10@ DATAA@, AS, AI, @@, 85,5, A9, BB, 85,4,A 
9, 20,85,7,A5,7,91,5 

11@ DATACY, 7E, Fe, 19,E6,7,C8,C@, DF,F@, 
6,C@,0,F@,9,DO,EB,A6,& 

12@ DATAE®@, BF, D0,F4, 60,E46, 6, DO, FS, &@, 
AI, 20,85, 7, D8,E3, 6a 


Fig. 7.5. (a) The assembly language version, (b) the BASIC listing for the 
flowchart of Fig. 7.4. 


memory. The starting address of the text screen is loaded into 
addresses $25 and $26, plus Y register, as before, but this time 
address $27 is also used to hold the first character code of $20. The 
loop starts by loading the accumulator from this address, and using 
Y-indirect addressing to store it inthe screen memory. The next step 
tests what this number in the accumulator is. If it is less than $7E, 
well and good. If not, then the RSTOR routine will restore the value 
of $20 in address $27 and resume normal service at the point which is 
labelled NXT. 

Having dealt with this problem, the rest of the program follows 
lines which should be more familiar to you. The address $27 ts 
incremented, so that we get the next ASCII code number, and the Y 
register is also incremented. We now have to test for the last screen 
address, just as we did in the program of Fig. 7.3, and for the Y 
register reaching the value of §. These loops follow the same pattern 
as before. Try it, and you'll see the full set of text-mode characters 
appearing, repeated several times over the whole screen. This is a 
good example of howa simple program can be extended so as to do 
much more than the original version. It’s an important point, 
because a lot of machine code programming is of this type. If you 
keep a note of all the assembly language programs that you have 
ever used, along with what they did, then you'll find that this ‘library’ 
is a very precious asset. Very often, you'll find that any new program 
that you want to write can be done by modifying or combining (or 
both) old routines that you are familiar with. Another big advantage 
of this is that an old routine is a trustworthy routine — a split-new one 
needs a lot of testing before you can rely on it. 
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Save it! 


At this point, when our programs are getting noticeably longer, and 
doing more interesting things, it’s time to look at the topic of saving 
machine code program on tape. Now you aren’t in any way obliged 
to do this. Our machine code programs have all been, so far, in the 
form of a BASIC program that poked numbers into the memory. 
You can, obviously, just save this BASIC program, and it will create 
the machine code for you whenever you want. When you are using a 
mixture of BASIC and machine code, this is the ideal way of saving 
and loading the machine code bytes. There are times, however, when 
you need as much of the memory as possible, and another piece of 
BASIC program is as welcome as an elephant in a space capsule. 
You may also want to put on cassette a program that isa mixture of 
BASIC and machine code, so as to make it difficult for anyone to 
copy it. Either way, you'll want to make a direct recording of the 
bytes that are stored in the memory. The ordinary BASIC 
commands of the Oric/ Atmos can cope with this, but, as we'll see, in 
a sligntly different way. 

Like most other machines, the Oric/ Atmos has special BASIC 
commands for saving and reloading machine code programs. These 
use the familiar CSAVE and CLOAD commands, but with a 
different syntax. The idea is that the CSAVE command will save a 
list of bytes, all the bytes that are stored between a starting address 
and a finishing address. The CLOAD command, similarly, will load 
a list of bytes to the same range of addresses as they were saved from. 
You can also specify that your machine code program will run as 
soon as it has been loaded, which saves you from having to 
remember which address number to use with CALL. 

Let’s try it out. Use the program of Fig. 7.5 to create a machine 
code program. The starting address is $9600, and the finishing 
address is $9635. This is because the program poked bytes from ) to 
53 (denary) and 53 denary is $35 hex. The CSAVE command must 
therefore read: 


CSAVE“SCRCOVER”,A#9600,E#9635 


and if you want the program to run as soon as it is loaded, you add 
another comma and the word AUTO. Start your recorder and press 
the RETURN key (as fast as possible after starting the tape), and the 
machine code will be recorded. This takes less time than recording 
the BASIC poke program. 

Loading a program of this type is much easier. You don't have to 
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specify any address numbers, particularly if you use AUTO. Simply 
type: 


CLOAD“SCRCOVER” 


and press RETURN. Your machine code program will load and, if 
you used AUTO, will run also. If you didn’t use AUTO, you will 
have to start the machine code with a CALL, using the correct 
starting address. A machine code load with auto-run is very difficult 
to disable, and it’s possible to make a machine code program which 
will then load and run a BASIC program. This is a good way of 
protecting your programs against copying — but more of that later. 

Don’t imagine, by the way, that this ability to save and load bytes 
applies only to machine code programs. Any section of the memory 
can be saved and reloaded by using this method. Since the text 
screen is controlled by the bytes in memory from $BBA8 to $BFDF, 
you can CSAVE and CLOAD text and LORES screen patterns in 
this way. You can similarly load and save HIRES screen patterns by 
using addresses $AQ9@ to SBF#F. The patterns on the LORES 
screen will be rather spoiled by the READY message that appears 
after loading, though, so for best results, you should disable this by 
using a piece of program, such as a closed loop, that stops the end of 
a program. 


Take a message 


After that brief interlude on the subject of saving and reloading 
machine code, let’s get back to the programs. We left Fig. 7.5, you 
remember, writing characters on the screen. It’s time now that we 
looked at ways of putting something more interesting on the screen, 
and letters look like a reasonably simple start to this type of 
programming. What do we have to do? Well, to start with, we need 
to store some ASCII codes for letters somewhere in the memory; we 
can’t just use a string variable as we would in BASIC. We will have 
to know the address at which the first of the letters is stored, and how 
many letters are stored starting at this address. After that, we should 
be able to work a loop which takes a byte from the ‘text space’ (where 
the letter codes are stored) and put it into the screen space (the screen 
addresses). We've already used the main type of instruction that we 
need for this sort of thing — the auto-incremented load or save. To 
work, then. 

We start, as always, with a flowchart. It’s not so easy this time, 
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because we need a different way of ending the loop. We could count 
the number of letters that we want to place on the screen, but I want 
to look at a different technique this time - using a terminator. You 
are probably familiar with this idea used in BASIC programs. A 
‘terminator’ is a byte which the program can recognise as a special 
character, one which is not, for example, part of a message. A 
convenient terminator for a lot of purposes is #, so we'll try that. The 
difficulty arises because we don’t want this terminator printed on the 
screen. As it happens, because of the way that the Oric/ Atmos uses 
its code numbers, the number @ actually would not cause any 
bother, but we’ll avoid printing it all the same. This means that we 
must test the accumulator between loading the byte from memory 
and placing it into the screen memory. That, as you'll see, makes the 
loops slightly more complicated. 

The flowchart that we need is shown in Fig. 7.6. What we have to 








Load from TXT 


Yes 


No 
Store at 
SCRN 


Increment TXT 
and SCRN 
addresses 


Fig. 7.6. A flowchart for printing a message on the screen. 
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do is to store two addresses. One of these will be familiar, it will be 
part of the screen memory. This has to be the address of the first byte 
that we will want to put on the screen. The other address has to bea 
store address, the start of a string of bytes that will be used to store 
ASCII codes, and which will not be used for anything else. We can 
clear things up for ourselves by giving these two addresses label 
names. I’ve chosen SCRN for the screen memory, and TXT for where 
we're storing the codes. What we do, then, having allocated these 
addresses, is to load a code from TXT, and increment the TXT 
address. We then test the character, to see if it’s our terminator of 9. 
If it is, we want to leave the program at once. Ifit’s not, then we store 
this byte at SCRN, increment the SCRN address, and go back for 
another character. Now this gives us a flowchart which has two 
jumps. One of these is the ‘go back’ part, the other is the part that 
goes to the end. What is this going to look like in assembly language? 





(a) 
TXT EQU $9656 
‘SCRN EQU $BDBB 
LDX #306 zero X register 
LOOP: LDA TXT,X get text character 
CMP #806 sis it end? 
BEQ OUT send if so 
STA SCRN,X store to screen 
INX ;pick next one 
BNE LOOP ;go round again 
OUT: RTS sback to BASIC 





(b) 1@ HIMEM#9S5FF: A=#9600: B=#965@e 

20 M$="This is your life!" 

3@ FORN=@T0O17: POKEB+N, ASC (MIDS (M&, N+1 
.1)):NEXT 

4@ POKER+18, @ 

5@ FORN=@TO15:READ D¢ 

6@ POKEA+N, VAL ("#"4+D%) : NEXT 

79 CLS:CALLA 

19@ DATAA2, @, BD, 50, 96,09, @,F@,4, 9D, BB 
.BD,E8, De, FS, 60 


Fig. 7.7. (a) The assembly language for the message routine, (b) the BASIC 
listing. 
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The answer appears in Fig. 7.7(a). It follows the flowchart pretty 
exactly, and the parts we particularly need to look at are the BEQ 
and the BNE steps. At the BEQ step, the accumulator has been 
loaded from the TXT piece of memory, whose starting address is 
$9659. I have picked an address which is well clear of the addresses 
that we are using for the program. The accumulator is loaded using 
X-indexed addressing, and the X register has been loaded with zero. 
As a result, the first load of the accumulator will come from the 
address $9659. This will be the byte $54, which is the ASCII code 
number for the letter ‘T°. The CMP #9 step is put following the load 
so that the @ byte can be detected at the end of the message. BEQ 
means ‘branch if equal to zero’, and the displacement that follows 
this Instruction byte will take the program to the RTS instruction, 
labelled OUT, skipping over the steps between the BEQ and the 
RTS. If the byte is not zero, however, it is stored at the SCRN 
address, using the X register once again for indexing. We then have 
to get back for another character. Since this needs a jump, and one 
that must always be made at this point, we could use the JMP 
instruction. JMP, however, has to be followed by a full two-byte 
address, and it’s a lot easier to use BNE. At this point in the program. 
the byte in the X register can never be zero (unless you're trying to 
place too many letters on the screen). As a result, BNE will always 
return the program to the LOOP position. This will continue untila 
zero is loaded into the accumulator, and the BEQ OUT step forces 
the program to return to BASIC. 

That explained, we can convert into the form of a BASIC 
program, as Fig. 7.7(b) shows, and try it out. We'll place the bytes 
into memory in a fairly simple way, by poking them into memory 
from a string. This is done in lines 20 to 49. Lines 59 and 69 then put 
the machine code into place, and line 7@ runs it. When it runs, you 
see the message appearing. 

Perhaps we can deal now with one other point about placing text 
on the screen. In all of the preceding programs that use text on the 
screen, we have simply accepted the black and white text that always 
appears when we use direct poking of numbers into screen memory. 
We can, of course, do a lot better. What we shall do is to place some 
colour codes into memory as well, so that the screen action will be 
affected by these as well. We can use both foreground and 
background colour codes, remembering that each colour code 
number will affect all the letters that follow it on a line. 

This sort of thing needs only a comparatively small change to a 
machine code program. Figure 7.8 shows the BASIC version. Line 
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1@ HIMEM#95FF : A=#96400: B=#9650 

29 M$="This is your life!" 

25 POKER, 19: B=R+1:POKER, 4: B=Bt+1 

3@ FORN=@T017: POKER+N, ASC (MIDS (M#, N+1 
31)) NEXT 

4@ POKER+18,@ 

0@ FORN=@TO15:READ D& 

6@ POKEA+N, VAL ("#"+D$) = NEXT 

7@ CLS:CALLA 

109@ DATAA2, @, BD, 50, 96,C9,9,F@,6,9D, BB 
, BD, E8,D0,F3, 4a 


Fig. 7.8. Modifying the routine so that the colour addresses are poked. 


25 has been added to poke two colour code numbers into the 
memory ahead of the text message. This gives a yellow background 
and blue lettering for your text. In a machine code program which 
produced text on the screen, of course, you would not have a string 
used to place the characters. You would have to place the ASCII 
codes in memory before you recorded the machine code. This could, 
however, be done in exactly the way as is shown in Fig. 7.7 and Fig. 
7.8. It’s another small step forward! 


Sailing out of the port 


When I described the action of the computer system in Chapter I, 
the idea of a port was raised. As far as a computer is concerned, a 
port is any chip or collection of chips that carries out the actions of 
sending bytes out or taking bytes in. As it happens, the port 
arrangements of the Oric/ Atmos are documented in the manuals 
(particularly so in the Atmos manual), but you would not normally 
need to make use of them unless you wanted to arrange machine- 
control or other interfacing projects. This type of work is rather 
more complicated, and it’s beyond the scope of this book. The 
reason is that the port chip is as complicated a device as the 
microprocessor itself, with its own registers and memory addresses, 
and it would need a book as long as this one to explain its actions 
fully, starting from scratch. Once you have had some experience of 
machine code programming, however, you will be able to take port 
programming in your stride, and you might find my book Practical 
Microprocessor Systems (published by Newnes) of use to you. It’s 
even available in Japanese translation! 


Chapter Eight 


Debugging, Checking 
and Oricmon 


Debugging delights 


Now that you have experienced some of the delights of machine 
code programming, it seems fair to mention some of the drawbacks. 
One of these is debugging. A ‘bug’ is a fault in a program, and 
debugging is the process of finding it and eliminating it. It all sounds 
rather insecticidal, but it’s nothing like as easy as that! 

It’s easy to say, I know, but the first part is prevention. Check your 
flowchart carefully to make sure that it really describes what you 
want to do. When you are satisfied with the flowchart, turn to the 
assembly language to make sure that it will carry out the instructions 
of the flowchart. When you are happy with this, check that the bytes 
you intend to poke into memory are the bytes which correspond to 
the assembly language instructions. One thing to watch very 
carefully is that you have the correct code for the addressing method 
that you are using. If you check each stage in the development ofa 
program in this way, you will eliminate a lot of bugs before they are 
up and flying. Don’t feel that you are a failure if the program still 
doesn't run ~ unless a machine code program is very simple, there's a 
very good chance that there will be a bug in it somewhere. It happens 
to all of us — and it’s only by experience that you can get to the stage 
where the bugs will be few in number and easy to find. 

If you use a good assembler, one source of bugs completely 
disappears. Human frailty means that the process of converting 
assembly language instructions into machine code bytes is error- 
prone. That’s because it means looking up tables, and anything 
which involves looking from one picce of paper to another is highly 
likely to introduce mistakes. I shall briefly describe the action of the 
Oricmon assembler later in this chapter. At the time of writing, there 
were several assemblers available for the Oric/ Atmos, but Oricmon 
has several advantages, two of which are that it is itself written in 
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machine code and that it contains several valuable monitor actions. 
There’s more on monitors later in this chapter as well! If machine 
code has really caught your imagination, and you feel that you want 
to branch out into more advanced work than we have space for in 
this book, then a good assembler and monitor program is an 
essential. You will have to be prepared to pay quite a lot for sucha 
program. If, however, you intend to be just a dabbler, spawning the 
odd drop of machine code now and again, then the poke-to-memory 
methods that we have used so far will be perfectly adequate. Using 
these methods, however, means that there will be bugs lurking in 
each corner of the code. The main cause of these bugs is weariness. 
Converting an assembly language progam into hex bytes, and 
writing them in the form of DATA lines fora BASIC poke program 
is a tedious job, and all tedious jobs result in mistakes (ever drivena 
‘Friday’ car?). Faulty address methods are one common result of 
tedium, and simply writing down the wrong code is another. One 
very potent source of trouble is with branch displacements. You may 
get the number wrong somewhere between subtracting addresses 
and converting a number (particularly a negative number) to hex. 
Another problem arises when you modify a program, and add code 
between a jump instruction and its destination. Having done that, you 
then forget to alter the size of the displacement byte! This is a 
problem which simply doesn’t arise when an assembler is used. An 
incorrect jump will nearly always cause the computer to lock up. 
You can often restore control with the use of the RESET button, but 
not always, and you will sometimes lose your program (you did 
record it, didn’t you?). Another form of incorrect branch is doing the 
opposite of what you intended, like using BEQ in place of BNE or 
the other way round. Careful thought about what the jump will do 
for different sizes of bytes should eliminate this one. 

A lot of problems, as I have already said, can be eliminated by 
meticulous checking, and it pays to be extra careful about branch 
displacements, and about the initial contents of registers. A very 
common fault is to make use of registers as if they contained zero at 
the start of the program. You can never be certain of this. It’s safer, 
in fact, to assume that each register will contain a value that will 
drive the computer bananas if it is used. With all that said, and with 
all the effort and goodwill in the world, though, what do you do if 
the program still won't run? 

There’s no single, simple, answer. It may be that your flowchart 
doesn’t do what you expect it to do, and if you didn’t draw a 
flowchart, then you have got what you deserve. It may be that you 
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are trying to make use of an Oric/ Atmost ROM routine and it doesn’t 
Operate in the way that you expect. When you have enough 
experience in machine code to follow more elaborate programs, you 
can make use of a disassembly of the ROM. At the time of writing, 
there is no disassembly of the Atmos ROM. There was one available 
for the older Oric-1, ina book called The Oric-1 Companion, by Bob 
Maunder (published by Linsac). Once again, this is for the really 
serious Oric/ Atmos machine code programmer. All I can do here is 
to give you general guidance on removing the bugs froma program 
that seems to be well-constructed but which simply doesn’t work 
according to plan. 

The first golden rule is never to try out anything new in the middle 
of a large program. Ideally your machine code program will be made 
up from subroutines on tape, each of which you have thoroughly 
tested before you assembled them into a long program. In real life, 
this is not so easy, particularly when the subroutines exist only as 
DATA lines for BASIC poke programs. As usual, users of an 
assembler have the best of it, because they can keep assembly 
language instructions stored like BASIC programs, and merge and 
edit them as they choose. 

The next best thing to keeping a subroutine library on tape is to 
have extensive notes about subroutines. In addition to routines of 
your own, you can keep notes on routines which you have seen in 
magazines. Personal Computer World runsa series called SUBSET. 
This consists of several general-purpose machine code routines each 
month. Most of these are for the two most-used microprocessors, 
the Z80 and the 6502. Even if you don’t use the routines, the way in 
which they are documented should give you some ideas about how 
you should keep a record of your own routines - | personally would 
buy the magazine for this feature alone! If you are going to use a new 
routine in a program, it makes sense to try it on its own first so that 
you can be sure of what has to be placed in each register before the 
routine is called, and what will be in the registers after. Look at the 
examples in SUBSET, and see how well this information is 
presented. (The editors of SUBSET, Alan Tootill and David 
Barrow, have recently published 6502 Machine Code for Humans 
(Granada) which is recommended as further reading after you have 
finished this book.) 

Planning of this type should eliminate a lot of bugs, but if you are 
still faced with a program that doesn’t work, and which you don't 
want to have to pull apart, then you will have to use breakpoints. A 
breakpoint, as far as the Oric/ Atmos operating system is concerned, 
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is the byte $69. This is the RTS byte, and its effect is to return to 
BASIC. When you are back in BASIC, you can examine the 
contents of memory by using PEEK instructions. The principle is to 
Pick a point in the program at which something is put into memory. 
If you place a $69 byte following this, then when the program runs, it 
will return to BASIC immediately after the memory is used. By 
using a PEEK, you can then check that what has been loaded into 
the memory is what you expect. If it isn’t, you should know where to 
look for the fault. If all is well at this point, then substitute the 
original byte that belongs in place of the $69, and place the $6@ at the 
next address following a memory store command. This type of 
action, however, is much more easily carried out with the help ofa 
good monitor program, of which more later. 

The most awkward fault to find by this or any other method isa 
faulty loop. A faulty loop always causes the computer to lock up. 
When this happens, pressing the RESET button under the case of 
the Oric/ Atmos will not normally get you back to normal service. 
You will then have to switch off and then on again, losing the 
program. You'll be glad then that you recorded the program before 
running it! The main cause of this sort of thing is a loop back to the 
wrong position. For example, if we had a program part of which 
read: 


LDX,#$FF 
LOOP: DEX 
BNE LOOP 


we could encounter problems. Suppose that this was assembled by 
hand, and we made the branch back to the LDX instruction rather 
than to the DEX instruction. This would result in the X register 
being kept ‘topped up’, and never decremented to zero, so that the 
loop would be endless. A mistake like this is easily spotted in 
assembly language, because the position of the label name is easy to 
check. It is very much more difficult to find when you have only the 
machine code bytes to look at. As always, taking care over loops is 
the only answer, and the method that has been shown in this book of 
calculating and checking displacements is a good precaution. 


Monitors 


I mentioned monitors briefly earlier on in this chapter. This has 
nothing to do with a TV monitor, which is a sort of superior quality 
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TV display for signals. A monitor in the software sense is a program, 
one which checks (or monitors) each action of a machine code 
program. A monitor is (or should be!) a machine code program 
which can be put into the memory at a set of addresses that you 
aren't likely to use for anything else. Once there, a monitor allows 
you to display the contents of any section of memory (in hex), alter 
the contents of any part of RAM, and inspect or alter the register 
contents of the 6502. These are the most elementary monitor 
actions, and it’s useful if a section of program can be run, 
breakpoints inserted, and registers inspected ona working program. 
The ideal monitor would be one which could carry out the steps of a 
machine code program one at a time, displaying the register and 
memory contents at each step. Oricmon comes very close to this 
ideal. 

An even better choice is a combined monitor, assembler and 
disassembler. The monitor allows you to debug programs, the 
disassembler lets you find out how ROM routines (and other 
machine code programs) work, and the assembler allows you to 
assemble correct code into memory from your assembly language 
programs. Unfortunately, you have to be careful about your choice 
of such programs. Some are in BASIC, which means that they are 
slow, very long, and they occupy a piece of memory that you may 
need. One that I sent for (‘48-hour delivery guaranteed’, it said) had 
not arrived in three weeks, and when it did, it refused to load into the 
Atmos. Another arrived fast enough, but was in BASIC, contained 
bugs (like numbers which were printed in background colour!) and 
took forever to load. It also used very non-standard mnemonics, 
which meant that every assembly language program had to be 
altered. Tansoft produce a combined monitor and disassembler 
which has some assembly actions. This program is called Oricmon., 
and the remainder of this chapter is devoted to the facilities which 
are available in this program. I quote from the Oricmon manual here 
because my copy of Oricmon would not run in my Atmos, though it 
appeared to load. It was a tape that was intended for the Oric-! and 
had not been modified. 


Oricmon monitor 
The Oricmon assembler/ monitor contains among its many facilities 


an excellent monitor. The program should be self-starting, and its 
monitor facilities should be available to you whenever it has loaded. 
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These facilities are obtained by a set of simple commands, which you 
can very soon memorise, so that it will not take very long to become 
accustomed to the use of Oricmon. The facilities are, in order of 
presentation in the manual, memory inspection, change data, enter 
text, hex arithmetic, move data, compare memory, and return to 
BASIC. The use of the ‘P’ key allows you to have results printed on 
paper (if you have a printer) or not as you choose. In addition to the 
monitor facilities, Oricmon allows disassembly (translating code 
into assembly language) and a simple assembly system. An 
important point to note is that a// numbers are assumed to be in hex, 
so you will need to brush up your hex in order to use Oricmon. 


Memory magic 


One of the most-used actions of a monitor is to check what has been 
stored in memory. You can, of course, do this in BASIC by making 
use of PEEK, but the monitor action is much more flexible and 
useful. The main point is that you need only a brief command when 
you use the monitor, and you can inspect as much memory as you 
want with very little effort. If you want to see what is stored at only 
one location in memory, you simply type the address in hex, and 
press the RETURN key. The address will then be printed at the left- 
hand side of the screen, with a colon following it, and the byte that is 
stored at this address following the colon. You can then inspect the 
memory from this point on simply by pressing the RETURN key. 
Each time that you press the RETURN key, you will see displayed 
on the screen a starting address, and the next eight bytes that are 
stored in the memory. For example, the display of bytes from #9900 
might look like: 


9900: A9 OC 29 85 93 A2 09 BD 


which shows the bytes that are stored in memory locations $9909 to 
$9907. The next line (press RETURN again) would show the bytes 
for addresses $9998 to $990F and so on. 

Very often when you are inspecting memory in this way, you may 
be looking for ASCII codes. To make this simpler, Oricmon allows 
you to vary the display of memory. When you first use the display, 
you will see hex codes displayed. By pressing the Z key, you can 
change the display to ASCII, so that each ASCII code will print as 
its ASCII character instead of as a hex code. In this mode, any 
number that is not an ASCII code will be displayed as a dot. 
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Pressing the Z key again will give mixed display, with all ASCII 
codes shown as characters, and all others as hex codes. This is useful 
if you have a piece of memory which contains a mixture of 
commands and text. Pressing the Z key again restores hex printouts. 

If you want to display a block of memory between two addresses, 
then you can obtain this in a simpler way than by pressing the 
RETURN key. You simply type the start address, a dot, and the 
finish address, then press RETURN. For example, typing 
990).998% and then RETURN will display the contents of memory 
between these addresses. There must be no spaces between each 
address and the dot. If, having obtained this display, you then find 
that you want to see some more, you can add another ending address 
by typing it following a dot. Forexample, typing .99A@ (RETURN) 
following the previous example will make the display continue to 
this new address. 


Entering data 


Another useful monitor facility is that of altering data bytes in the 
memory. Again, this is something that you can do from BASIC by 
using POKE, but the monitor allows more convenient control over 
what you are doing. Suppose that you want to enter the bytes Ag C9 
at address $9692. You would type: 


9692:A9 C9 


and then press RETURN. There must be no space either side of the 
colon, but you ust put a space between the two data bytes. You 
can, of course, enter more than two data bytes in this way, but you 
must be sure to type a space between each byte and its neighbours. 
Each data byte should consist of two characters. 

Text can also be entered in this way, which is very convenient if 
you are writing a machine code program which displays text on the 
screen. Text is entered by typing the address at which you want the 
text to start, then a single apostrophe (’), the text, and another 
apostrophe. Note that no colon is used in this case. There must, as 
usual, be no space between the end of the address and the first 
apostrophe. After you have typed the second apostrophe, press 
RETURN. If, for example, you wanted to have the ASCII codes for 
‘THIS IS YOUR LIFE’ stored starting at address $9600, you would 
type: 


9600 ‘THIS IS YOUR LIFE’ 
and then press RETURN. 
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Hex arithmetic 


Unless you possess the machine code programmer’s ultimate status 
symbol, a calculator which works in hex, it’s likely that you will 
avoid hex arithmetic like the plague. Oricmon allows you to carry 
out hex arithmetic reasonably painlessly, simply by typing the 
quantities and pressing RETURN. For example, typing $A+2C 
(RETURN) will print up the answer 36, and BC—FI will give CB. 
Only two-digit arithmetic can be carried out, but this is all that you 
normally need, because you can usually ignore the leading two bytes 
of addresses when you are performing hex arithmetic. You must, 
however, be rather careful when you are using this hex arithmetic to 
calculate branching displacements, because it does not allow for 
subtracting that extra 2. 


Memory blocks 


Oricmon has very useful actions that copy data from one part of 
memory to another, and which can compare data in two different 
parts of memory. Suppose that you have a set of bytes stored in 
addresses $8000 to $805, and you want them copied to a part of the 
memory that starts at address $5909. All you need to do is to type: 


SPPI<8 999.8959 M 
and then press RETURN. The block will be copied into its new set of 
addresses ($5999 to $595), and the original block between $8099 
and $8950 will remain in the memory. In this command (no spaces, 
remember), the letter ‘M’ is used to mean ‘move’. If you use the same 
arrangement with the letter ‘V’, such as: 


SPPP<8PP9.8P5PV 
then what happens is that the block of memory which starts at 
address $5999 is compared, byte by byte, with the block from $890 
to $8950. If any byte in the first set (the set that starts at &599Q in 
this example) is not matched perfectly with the byte at the 
corresponding address in the other block, then the address and the 
size of the odd byte is displayed. 
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Disassembly 


‘Disassembly’ is the opposite of assembly; it means the translation of 
machine code bytes into assembly language. For example, the 
disassembly of 8D $2 94 would give STA $9492, which is a lot easier 
to understand. A disassembler is a very useful way of reading a 
machine code program. It’s particularly useful if you want to 
understand how a machine code program works, and it’s almost 
essential if you want to find out how other machine code 
programmers go about solving problems. 

That said, very few disassemblers go all the way. Most simple 
disassemblers can’t distinguish between machine code commands 
and ASCII text, for example, and there are very few disassemblers at 
any price or for any machine which will put in labels. The normal 
action when a branch command is encountered is to put in the 
address to which the jump is made. This is reasonably satisfactory if 
you have a printer, because you can inspect the printed copy later, 
and put in your own labels to show where the jumps go to. If you are 
tied to working on the screen, however, you will need to confine your 
disassembly to reasonably small chunks of machine code. 

The Oricmon disassembly action is called up by typing L 
immediately following an address. As always, the address must be in 
hex, and there must be no space between the address and the letter L. 
When the RETURN key is pressed, fifteen lines of disassembly will 
be shown on the screen (or printer, if you have one). Each line shows 
the address of the first byte of the command, the hex codes, and the 
assembly language that corresponds to the codes. If you want 
another fifteen lines, you need only type another letter L, and press 
RETURN again. You can request multiples of fifteen lines (for a 
printer) by pressing the L key several times before you press 
RETURN. 

If the machine code that you are disassembling contains text, then 
the disassembler will try to disassemble this as if it were code. Sooner 
or later, it will come across a byte which is nota valid 6502 code, and 
it will print a group of three question marks instead of a disassembly 
command. When you see ??? in a disassembly, you will need to check 
all the code around this point to find where the text begins and ends. 
You may have to repeat some disassembly from the address 
following the address at which the text ends. This is because the last 
text code may have been read as a command, making the 
disassembler read the next byte, a real instruction, as if it were data. 
If the disassembler gets started on the ‘wrong foot’ like this, it will 
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eventually get back to normal, but you may get incorrect 
disassembly for several lines. 


The assembler 


In some ways, the assembler is the most useful part of any package of 
this type, because this is the part that allows you to create machine 
code. The Oricmon assembler, unlike some others, uses correct 6502 
mnemonics, with the # sign indicating immediate loading, and all 
numbers in hex. Unfortunately, no labels can be used. As labelling is 
one of the most useful features of assembly language, this is a most 
unfortunate omission. It does not make the assember useless, 
because addresses can be used, but it makes the assembler slower in 
action, and more difficult to use. You have to note the address for 
each point that you have labelled. If you have a branch toa line that 
has not yet been written, you must fill in a ‘guess’ address, and then 
rewrite the line later when you have found the correct address. It’s 
still a lot easier than assembling by hand, though! 

The Oricmon assembler will assemble each line as code into 
memory when you press RETURN. This means that your ‘source 
code’, the lines of assembly language, cannot be recorded. This ts 
another unfortunate omission, because it’s a lot easier to record, 
replay and alter source code than assembler machine code. Each line 
of assembly language command has to start witha semicolon. If you 
are entering a long program, this can be tiring, so the Y key can be 
pressed to make the semicolon sign appear automatically in each 
line from then on. 

You will want to specify the address at which assembly is to start. 
This has to be done before you press the Y key for automatic 
semicolons, so that you can type the start address, then a semicolon, 
and then the first assembly language command. You are limited as 
to the range of addresses that you can use. The Oricmon program is 
located in the memory from $8B0 to $97FF, and it also makes use 
of addresses $49 to $50. This means that you cannot assemble 
code into two of the most useful parts of memory which you would 
normally use! On some other machines, monitor programs can be 
shifted around in the memory so as to leave the bits that you want 
free, but this is not possible with Oricmon. The assemblers which are 
written in BASIC do at least allow both of these important parts of 
memory to be used. However, if you are developing machine code 
programs which are to be used instead of BASIC, rather than along 
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with BASIC, you can assemble in the ordinary BASIC addresses 
from $509 onwards. 

As you press RETURN on each command line, the assembly 
language will be converted into code, and the code will be displayed. 
You must make a note of the address at which the code starts if you 
are going to use this address as a label. If you have entered an 
impossible instruction, the code will not appear, but an error 
message will! At the end of your program, you can press the DEL 
key to remove the semicolon, and the Y key to ensure that you don't 
get any more semicolons. Once this has been done, you are back into 
the ordinary monitor commands again. If the last command of your 
machine code program is an RTS byte, then the program will return 
to BASIC when it has finished. You may, however, want to check it 
while Oricmon is operating. If so, make the last byte that is executed 
a BRK instead of RTS. This will ensure that the program will return 
to Oricmon after running ~- if all goes well! 


Execution hour! 


Once you have assembled a program, you will want to record it. 
Oricmon has commands which will let you save and reload the code 
without returning to BASIC. This should a/wars be done before you 
make any attempt to run a machine code program that you have 
assembled — we’ve gone into the reason in previous chapters. Once 
this has been done (remember that the Slow cassette speed is much 
more reliable for this type of save), you can try to run the program. 
You type the address of the start of the program, then the letter G. 
As usual, the address will be in hex, and there must be no space 
between the last character of the address and the letter G. When you 
press RETURN, the program will execute, and your moment of 
truth has come. If you ended the program with a BRK, then 
Oricmon will take over when your own program ends, and you can 
carry out a post-mortem! 


Problem sorting 


When a program returns to Oricmon, you will see a display on the 
screen. This will start with an address, which is the address number 
following the end of the program. The rest of the line shows the 
numbers that are stored in the 6502 registers. You can, in fact, find 
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out what is stored in the registers at any time by typing the letter X 
(then RETURN). Youcan alter the contents of the registers by using 
address numbers $45 to $49. This can be useful if you want to check a 
loop. You can puta BRK byte at the end of the loop, place values 
into the 6502 registers, and then execute from the start of the loop. 
By placing suitable values in the registers, you can find if the loop 
will execute correctly, but without having to trace it round each 
time. This is a useful action, and one which is not all that common on 
monitors, certainly not on Oric/ Atmos monitors. 

Another extremely useful action is tracing. This allows you to run 
a machine code program in slow motion, either automatically or 
manually controlled. If you enter the start address followed by the 
letter T, the program will run in slow motion. Each instruction will 
be executed, and the 6502 register contents will be printed out before 
the next instruction is carried out. A byte stored in $68 controls the 
speed at which this tracing isdone. You can stop the action by typing 
the backslash (\) character. If you find that this action is still faster 
than you want, you can type the starting address and the letter W. 
This will cause one instruction to be executed, and the register 
contents displayed. Another address and W are needed to carry out 
another instruction. The important point about both of these 
commands is that you do not necessarily have to start at the first 
command in the program. You ius! start ata command byte rather 
than a data byte, but this can be anywhere in the program. You can 
also alter the 6502 registers before you start tracing, and this, as | 
have indicated. allows loops to be executed in slow motion, and with 
a choice of values in registers. 

All in all, the Oricmon offers a lot of facilities, and it was 
unfortunate that my copy was not adapted to the Atmos. It’s likely, 
however, that by the time you read this, the adaptation will have 
been done, and you will be able to use this program. Despite the 
limitations of not being able to record source code, and of not 
permitting labels, Oricmon is useful, and a definite step in the right 
direction for the machine code programmer. 


Chapter Nine 
Last Round-up 


One of the main problems about writing a book that introduces 
machine code programming is knowing where to stop. There ts prac- 
tically no limit to what can be added now that you started in 
this business, and where you go from here will depend a lot on what 
your particular interests are. | have to confess that my main interest 
is in ‘utilities’, the programs that make a machine more useful to me. 
Any utility program should make a machine easier to use, perhaps 
by adding a new command to the BASIC. Perhaps it would be a 
good idea to take a look at some ideas for utility programs, and at 
the same time learn some more about the operating system of the 
Oric/ Atmos. 

Have you ever typed NEW and pressed RETURN, then suddenly 
realised that you had not recorded the program? The BBC Micro has 
a BASIC command word OLD that lets you get your program back 
after an error like that, provided you have not entered another 
program after using NEW. What about giving your Oric/ Atmos this 
capability? As you will know from the remarks that | made in 
Chapter 6, using NEW does not wipe out all the bytes of a program, 
it only changes the first two bytes to zeros. These are the bytes which 
would normally be used to find the address of the next line. If we can 
restore these two bytes, we can un-NEW a program! It’s even easier 
than it seems, because the second of these bytes will be 05, and we 
only need to find what the first one will be. This assumes that your 
BASIC program has started at $#50@ as usual. 

We should flowchart this problem, and Fig. 9.1 shows the result. 
If we start with a line number that is less than 256, then the byte in 
address $9594 will be zero, and the first byte of the program will be 
at address $9505. Now if we take each byte from then on, and check 
it, we will eventually come to a zero. This marks the end of that line. 
One byte beyond this point is the starting address for the next line. 
What we must do then, is to set a counter. It will have to start at 5. 


SS 


ewe SD ee 


— ss." =. 
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ST = start of BASIC address 


Get address 
ST +4 


Increment 
address 
(Low byte) 


Does it 
contain 0? 


Increment 
again 
(Low byte) 


Store at $501 
(Low byte) 


Store high byte 
at $502 





Fig. 9.1. The flowchart for the problem of recovering a program after using 
NEW. 


and be incremented as we look at bytes from addresses $9595 on. 
When we find a zero, we increment the counter once more, and then 
place this number into address $951, because it’s the low-byte of 
the next line address. We then put the number $05 into address 
$0502, because that should be the high-byte of the next line address. 
That's all! 
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The next step is to put this into assembly language, and then intoa 
BASIC program that will poke bytes into memory. We'll start in the 
way that we have been used to, as Fig. 9.2 shows. The X register is 
loaded with the number 4, and then incremented. The increment 


(a) 





LDX #804 ;count number 
MORE: INX incremented 

LDA $500,X sget code in first line 

BNE MORE ‘repeat if not zero 

INX sget start of next line 

STX $59! suse as low byte 

LDA #$@5 shigh byte is #5 

STA $592 ;put it in place 

RTS sback to BASIC 





(b) 1@ HIMEM#95FF : A=#94600 
2@ FORN=@TO17:READ Dt 
3@ POKEA+N, VAL ("#"+D$) = NEXT 
1@@ DATAA2, 4,698, BD,%,5, D4,FA,E8, SE, 1, 
3,A9,5,8D,2,5, 40 


Fig. 9.2. (a) The assembly language and (b) the poke program for the ‘un-new’ 
action. 


action comes at the start of a loop, so that the X register will be 
incremented on each pass through the loop. We then load the 
accumulator from $9509, X-indexed. This means that on the first 
time round, the accumulator will actually be loaded from $9595, 
because of the value of X. This is the first token byte of the program, 
and the first thing that we do is to test for this being 9. If it isn’t, we 
go back to the INX step, and repeat the indexed load. When we find 
a zero, the value of the number in X will be the count, from a starting 
number of $9509, of this address position. Adding | to X will give 
the count to the next line. This count number is then placed into 
address $$501, and the number 5 is placed in address $9592. For 
example, if we found that the first zero was found with X= 19, then 
the INX step makes X = 29, and 20 is poked into $501, with 5 in 
$502, making the address $0529, which should be the next line 
address. We should now be able to list and run the program that was 
NEWed. We do this by typing CALL $9609. Try it! 


SRT RE BS TES Se SNS © ELS eh e See esse eee Seem ESS 
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Though it’s useful to be able to reverse the action of the NEW 
command by typing CALL $960@, a snappier method would be 
better. As it happens, the Oric/Atmos provides for other ways of 
calling up machine code subroutines. One of these, USR, need not 
concern us here (for more information see Appendix E), but there 
are two more, ! and &. The & sign is one that needs to be followed by 
other information, enclosed in brackets, so we'll leave it out. The 
! command looks more suitable for this job — but how does it work? 
To start with, you have to have your machine code stored in 
protected memory. The starting address of your machine code is 
then poked into two addresses, $92F5 and $$2F6. When the ! sign 
is typed, and RETURN pressed, the machine will find your machine 
code program and run it. Itsounds simple enough, so we'll give it a try. 

We could, of course, just DOKE the starting address into place, 
but what | would prefer is to create a completely machine code 
routine which you could record, with autostart, so that you could 
keep it ready in the machine. This means that the start of the 
machine code must contain routines that place the correct addresses 
into memory, and then return to BASIC. Figure 9.3 shows what has 
to be added; it’s only a few lines of load and store to get an address 
into $@2F5 and $#2F6. When the program is loaded, it will place the 





(a) 


ORG $0490 

LDR: LDA #$@B iIsb of start 
STA $92F5;into ! 
LDA #$04 :msb of start 


STA $2F6;into ! 
(un-NEW routine now put in starting at $949 B) 





(b) 1@ A=#40@ 
2@ FORN=0T028:READ D¢ 
3@ POKEA+N, VAL ("#"+D%) : NEXT 
4@ CALL A 
10@ DATAA, OB, 8D,F5,2,A9,4,8D,F4, 2, 62 
11@ DATAA2, 4,E£8, BD, @,5, D@,FA,ES8, SE, 1, 
5,A9,5,8D, 2,5, 6@ 


Fig. 9.3. Adding lines to the ‘un-new’ program so that it can be called by 
pressing the ! key (then RETURN) 
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bytes into memory, and when it auto-runs, it will put its start address 
into $92F5 and $$2F6. From then on, or until you use the reset 
button underneath the computer, pressing ! and RETURN will 
OLD your program, restoring anything that you have NEWed. 
Remember, though, that when a program has been NEWed, the 
VLT is set to an address near the start of BASIC. If you try to use a 
command like: 


FOR N=@ TO I@:PRINTPEEK (#509+N); “";:NEXT 


you will find that bytes of your program are replaced by VLT 
entries. This will usually stop the ! program from operating. The 
main novelty this time is that the program has been assembled to 
address $9490. The Oric/ Atmos reserves addresses $0490 to $042 
for your own short machine code routines. Anything that you 
assemble here will be untouched by any other machine action, 
whether BASIC or the action of the RESET button or anything else. 
Using the RESET button, however. will always reset the numbers in 
addresses $92F5 and $02F6. 


The stack 


You can’t get much further in machine code programming without 
coming across the word stack. A stack Is a section of memory, and its 
special use is to preserve bytes that have been kept in registers. 
There’s no special set of memory chips that we use as a stack - but we 
do set aside part of the RAM for this purpose. For a 6502 
microprocessor, we have to use memory in the address range $10) to 
$IFF. What you probably find difficult to understand at the 
present time is why we should ever need to use memory in this way. 

Let's take a simple example. Suppose you have a program in 
which the A register is being used to hold an ASCII code for a 
character. Suppose. now, in the middle of this program, that we 
want to create a time delay by making use of a count-down in the A 
register. Whenever we load the count value into the A register, we 
shall have replaced the ASCII code number that was stored there, 
and if we try to use the A register again in the rest of the program, we 
shall have to reload the code byte into it. This is what the stack ts for. 
By means of a single byte instruction, we can store the contents of 
the accumulator or the status register in the stack memory, and by 
using another similar instruction, we can get the values back into the 
correct registers again. The act of storing the register(s) on the stack 
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&1FF ~< SP = &FF 


&1FE 
&1FD 
&1FC PUSH 
Effect of PHA 
oP 
(A contains &42) 
Cee*7 &10¢ 
Empty stack PUSH 
(machine just Effect of 
switched on) PHA 
(A contains &7F) 
| 42 | RIFF 
&1FE 
| = ss AFD « SP=&FE 
Lemme & IFC PULL 
Effect of PLA 
———__> 
(A contains &29) 
Co") 3100 
&7F stored at PULL 
next address, 


Effect of 


stack pointer te ae 
moves 
(A contains &7F) 


_Sa2_| &1FF << SP=&FF 





Anow contains &42 


co! &109 
SP is moved up, 
then byte is copied 
as before 


| 842 | &1 FF 
TS«|«& FE ~ Sp=&FE 
| | FD 
Laman? &IFC 


Cc") &199 


&42 stored at 
highest address 
SP points to next 
free address 


[aa] BFF 
&1FE <t SP=&FE 
[ate 

Eat 


Anow contains &7F 


oS 


SP is moved up, then 
byte is copied. This 
does not delete the 
stored byte in the 
stack 


The stack is now ‘empty’, even 
though bytes remain stored. Any 
new byte pushed onto the 

stack will replace an old one 


Fig. 9.4. The stack actions illustrated. 


is called ‘pushing’, and recovering the values is called ‘pulling’. These 


actions are illustrated in Fig. 9.4. 


As a very simple example of the use of the stack, let’s add another 
‘utility’ to the Oric/ Atmos. This time we'll add a program that will 
make your friends wonder if your Oric/Atmos is a special one, 
because you will be able to produce the ‘shoot’ sound just by typing 
* instead of typing SHOOT and pressing RETURN. Yes, it’s simple 
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(Start address is put into 
keyboard loop) 


Save register(s) 


No 
Is character 
‘4 '? 


Make shoot 
sound 


Restore register(s) 


Fig 9.5. A‘shoot' utility flowchart. The idea is that you get the SHOOT sound 
each time you press the asterisk key 

enough - when you know how! Figure 9.5 shows the flowchart. 
What we have to do Is to intercept the keyboard routines. We 
already know how to do this, because we have done so in Chapter 6. 
We must then test the character in the accumulator. If this is the ‘** 
character, ASCII code $IA, then we will carry out the ‘SHOOT 
routine. After this, or if the character is not ‘*’, we go back to the 
normal routine. 

Figure 9.6(a) shows the assembly language routine in detail. 
Addresses $$23C, $$23D contain the address of the GTORKB 
routine. Now the GTORKB routine is in ROM, and can’t be 
changed, but addresses $9§23C, $923D are in RAM, and we most 
certainly can change them. Address $923B holds a JMP instruction 
code, so that the whole group of three bytes is a sort of ‘junction 
box’, leading to the GTORKB routine. If we change the numbers in 
$023C, $923D to the start of a routine of our own, and end our 


ey gr ee ee eee we 
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(a) 
ee ae a ee a eee ey 


ORG $9499 

LDA #$6B ;PATCH address Isb 

STA $923C into key routine addr. 

LDA #$04 :PATCH address msb 

STA $$23D ;into key routine addr. 

RTS sback to BASIC 
PATCH: PHA ‘save accumulator 

CMP ‘*° IS it asterisk? 

BNE OUT sout if not 

JSR $FABS sshoot routine 

PLA srestore accumulator 
OUT: JMP $EB78 sback to key routine 


Note: The Oric-1 may need a different JMP address. 


(b) 18 A=#400 
2@ FORN=@TO22:READ DS 
3@ POKEA+N, VAL ("#"+DS$) =: NEXT 
4@ CALL A 
1@@ DATAAS, OB, 8D, 2C,2,A9,4, 8D, 3D,2, 40 
,48,C9, 2A, D0, 3, 20, B5, FA, 68, 4C, 78, EB 


Fig. 9.6. (a) The assembly language and (b) POKE lines for the asterisk-shoot 
program. 


routine with a jump to the ROM address of GTORKB, then we shall 
have ‘patched’ our routine into the keyboard routine. This means 
that our routine will run each time GTORKB runs. 

Now, as it happens, GTORKBruns continually while the machine 
is showing its READY prompt. Because of this, it wouldn’t do to 
make the shoot sound occur each time GTORKB was used. By 
testing , however, we can make sure that only one character operates 
the SHOOT routine. The first line, however, is PHA. The character 
that is in the accumulator is going to be tested by the GTORKB 
routine, but if we call up the SHOOT routine, the accumulator will 
be used for something else, and we will have the wrong number in the 
accumulator when GTORKB runs. We avoid this by ‘pushing the 
accumulator on the stack’. What the phrase means is that the 
number stored in the accumulator is put into the stack memory. 
Now we test the accumulator for the presence of $2A, the asterisk 
sign. If it’s present, we continue with calling the shoot subroutine at 
SFABS. If the character is not the asterisk, and also after the shoot 
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routine, we ‘pull the accumulator off the stack’. This means that we 
put back into the accumulator the number that was there before we 
started messing around with the SHOOT sound. We can then jump 
normally to the GTORKB routine itself. 

Well, it works — after a fashion. When you type *, you hear the 
shoot sound effect, but things do not look right after that. For one 
thing, two asterisks in a row don’t both produce the shoot sound. 
For another, peculiar things seem to happen to the display after the 
asterisk has been used, as you'll see when you LIST. What’s wrong? 
The answer, almost every time, is that another of the registers is 
being corrupted. The SHOOT routine changes the values of all the 
registers, A, X, and Y. The effects that we see after using the 
program in Fig. 9.6 must be caused by the changes in the X or Y 
registers, perhaps both. The only way to be certain of not doing this 
Is to save both of these registers on the stack. 

It’s at this point that the 6502 microprocessor shows its age. It 
does not have any commands for saving the X or Y registers on the 
stack! What you have to do is to pass the value in a register to the 
accumulator, and then save the accumulator on the stack. It’s very 
long-winded, but that’s all we can do. Let’s design a Mark 2 version 
of the ‘shoot-asterisk’ program, in Fig. 9.7. This time, we'll test the 
accumulator right at the start of our routine. If the character in the 
accumulator is ‘*’, then we'll go through all the push steps, but if it 
isn’t, then we'll jump straight back to GTORKB. Only if the asterisk 
character is identified will we push the accumulator and the other 
two registers. We push the X register by the two steps TXA and 
PHA. This transfers the value in the X register into the accumulator, 
and then pushes this value on the stack. Similarly, TYA followed by 
PHA puts the value that was in the Y register on to the stack. By the 
time we get to the JSR SFABS step, all three registers have been 
saved on to the stack in this way. 

After the SHOOT routine has run, we have to get the register 
contents back. This is where we have to be very careful. We have to 
‘unstack’ in exactly the opposite order of stacking. The stack 
memory works on the ‘last-in-first-out’ principle. The last byte on 
the stack came from the Y register, so it’s the first to be restored, 
using PLA (pull from stack to accumulator) and TAY (transfer A to 
Y). Then we get the X register byte back by using PLA and TAX. 
Finally, another PLA gets back the correct byte for the accumulator 
itself. Note the order — the accumulator is always the first saved and 
the last recovered. Try the routine, and you'll see that it’s free of the 
troubles that affected the earlier version. 
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(a) 

ee ee a ee ee ee ee 
LDA #$9B sload as before 
STA $923C 
LDA #364 
STA $9$23D 
RTS 

PATCH: CMP ‘* sis it * 7 
BNE OUT back if not 
PHA save A 
TXA ;put Xin A 
PHA ;and save it 
TYA sput Yin A 
PHA ;and save it 
JSR SFABS ‘shoot routine 
PLA sget back Y 
TAY ;put it in place 
PLA sget back X 
TAX ;put it in place 
PLA sget back A 

OUT: JMP $EB78 ;key routine 





(b) 1@ A=#4ee 
2@ FORN=@TOS@:READ D¢ 
3Q@ POKEA+N, VAL ("#"+D$) s NEXT 
4@ CALL A 
100 DATAAI, OB, SD, SC, 2,A9,4, 8D, 3D, 2,69 
119 DATAC9, 2A, D@, OD, 48, 8A, 48, 98, 48, 20 
,B5, FA, 68, AS, 68, AA, 68, 4C, 78, EB 


Fig. 9.7. An improved asterisk-shoot program which preserves all of the 
registers. 


Program protection 


When you have spent a lot of time and effort on a program, you 
might want to prevent anyone from copying it while you were 
proudly showing it off on Club Night. A lot of time and effort goes 
into program protection these days, particularly in commercial 
programs, because without protection, it has been estimated that 
there will be ten illegal copies around for each one that has been 
bought. This is a sad situation, and there’s no simple way round it. 
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Anyone who has spent a lot of time on developing a program that 
will be sold for cash will naturally want to make as muchas possible 
out of it while there is an interest. A lot of commercial programs, 
particularly games, sell in huge numbers for a few weeks, and after 
that not at all. This is due to two factors — the arrival of a new game 
which everybody wants, and the existence of thousands of pirated 
copies of the old one. 

The other side of this problem is that software on cassettes is not 
very reliable, and even disks can crash. I would never use a program 
for which I did not have a back-up copy. In addition, I often want to 
alter a program to suit my own needs, perhaps by making a poor 
colour display into black/white, or by adding a printer routine in 
place of a screen display. If a program cannot be listed or copied, 
then I can’t do these things. 

Until something can be worked out (and it will take a lot to make 
people refuse to buy pirated software) you may want to protect your 
programs. I think that it’s important to emphasise that no program 
can ever be absolutely 100% copy-proof. You can, for example, buy 
twin-cassette recorders. You pop your program cassette in one side, 
a blank in the other, press the button and make a copy. When you 
record your Oric/ Atmos programs at the fast speed, though, these 
copiers do not work reliably. One up for protection! 

Since you can’t protect a program against anyone who is 
knowledgeable (like a good machine code programmer!) all that you 
can hope for is to protect against the kind of guy who borrows your 
tapes, makes a quick copy and gives the tapes back. This sort of 
copier won't spend any time in trying to figure a way round 
protection, he will just give up. Here are some tips. 


(1) Make your program auto-start, and make the last command 
NEW. This will ensure that when the programends, there is nothing 
to list — unless the user has my ! program in the memory. 


(2) Disable the stop (CTRL C) and RESET actions. This is most 
easily done by using POKE #1A, | at the start of your program, and 
POKE #1A,76 where the program should normally end. If CTRLC 
or the RESET button are used while address #1A contains I, then 
the operating system will go into a loop with an illegal quantity error 
message scrolling. The effect of this poke is to disable a jump which 
takes place to address $CCBQ when a BASIC program ends. 

(3) By doking a new address into #1B, #1C, you can make a jump to 
any other address when a BASIC program is stopped. This requires 
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more work, but it could allow you to run a machine code program 
which printed the message: 


COPY PROTECTED - HARD LUCK 


and disabled the keyboard. 


(4) Instead of using NEW at the program end, and a disabling step if 
the program is stopped, run a routine that completely clears the 
memory! By using JSR $C$9@ (or S$ECCC) you will run the routines 
that the Oric/ Atmos runs when it is switched on at first, ensuring 
that nothing remains in the memory. 


If you posses an Atmos, however, all of this work will be lost ifa 
copy-artist loads your program from a tape recorder that is not well 
matched to an Atmos. The error-detecting routine of the Atmos (not 
used in Oric-!) often works so well that it detects errors that aren’t 
there, and this will prevent the auto-start. The copier can then 
examine your program, and remove the POKE lines that are the 
usual dead give-away. It’s possible to prevent this by using a short 
machine code program to load in the BASIC - but that’s getting into 
advanced machine code work, well beyond the scope of this book. 
If this subject interests you, then keep your eyes on the Oric maga- 
zines for hints, and keep in touch with the user group. This is where 
all the useful information comes from. 


The renumber problem 


Another useful facility that the Oric/ Atmos lacks is a renumbering 
routine. Nowa rea/ renumbering routine is quite a piece of art. It will 
renumber all the lines of a BASIC program for you, taking any 
starting number (within reason) and any line increment (again 
within reason) that you like to use. Not only are the lines themselves 
renumbered, but also the line numbers in GOTO and GOSUB 
statements. A listing for a machine code renumber program can be 
several feet long, and that’s not what we are attempting. What I want 
to do here is to show how to start about a renumbering exercise, 
because this is something that can be very useful for a lot of other 
things. As always, it’s better to aim at something simple to start with. 
For that reason, we'll try to renumber, with a starting number that 
must be less than 255, and with line increments of 1. We'll also 
restrict the number of lines that can be renumbered, so that no line 
number must exceed 255 after renumbering. If that sounds modest, 
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remember that it allows you to renumber programs of up to 255 
lines. It also makes your renumbered programs very difficult for 
anyone else to alter, because they can’t squeeze another line in 
anywhere if the lines are numbered consecutively. 


(a) 





(Start number in address $97) 


LDA $9A 
STA $95 
LDA $9B 
STA $96 
LOOP: LDY #1 
LDA ($95), Y 
BEQ OUT 
INY 
LDA $07 
STA ($95), Y 
INY 
INC $07 
LDA #309 
STA($5),Y 
TAY 
LDA ($95). Y 
STA $08 
INY 
LDA ($05), Y 
STA $99 
LDA $98 
STA $05 
LDA $99 
STA $06 
BPL LOOP 
OUT: RTS 


;get start Isb 

sput it in $05 

sget start msb 

;put it in $06 

sindex 

sget next line high 
sif 6, end of program 
sbump up index 

sget start number 
;put in new number Isb 
sbump index 

sbump number also 
:for line number high 
;put it in place 

szero Y register also 
snext line Isb 

;put it in 08 

sbump index 

snext line msb 

sput it in 9 

sget Isb 

;put in current line 
‘get msb 

;put in current line 
srepeat actions 

sback to BASIC 





(b) 140 HIMEM#OSFF : A=#9600 
29 FORN=@T046: READ DS 


3@ POKE A+N, VAL ("#"+DS) NEXT 
19@ DATAAS, 9A, 85, 5,A5, 9B, 85,6,A%,1,B1 
5, FQ, 20,08, A5, 7,91, 5, CB. EG, 75959 
11@ DATA91,5, AS, B1, 5,85, 8.C8,81,5,85, 
9.0A5,8,85,5,A5, 9,985, 6,10, DA, 60 


Fig. 9.8. (a) The assembly language listing for the simple renumber program, 
and (b) the BASIC listing to poke the bytes into place. 
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The flowchart for this exercise is illustrated in Fig. 9.8(a). The idea 
is simple enough. The address for the start of BASIC is transferred 
from addresses $9A, $9B, into two other zero page addresses, $05, 
$96. I originally chose $25, $26, but found that these were being 
used for other things. This is something that you have to be very 
careful about when you make use of zero page addresses. It’s always 
a good idea to check them while you are testing a program, because 
the Oric/Atmos manual does not document their uses fully. 

Having transferred the address for the start of the first line of 
BASIC, the program nowstarts a loop. The Y register is loaded with 
1, and the indirect load LDA ($5), Y gets the byte from address 
$50 1+1 = $592. This will be the high-byte of the next-line address. 
When this is zero, we need to end the program (end of program 
marker), and the BEQ OUT step will do this. If it is not zero, then we 
can continue the renumbering procedure. The Y register is 
incremented, so that the number 2 is stored. The accumulator is 
loaded from address $97, which holds the starting line number. 
Conventionally, you might use 1@ here. This number is placed into 
address 5@3 by the indirect store command STA ($@5),Y. The Y 
register is then incremented again, and the address $97 is 
incremented to give the next line number, |! in this case. 

The accumulator is loaded with zero, and this is stored at address 
$594. This is the upper byte of line number, and in this simple 
program, we are not using this byte. Setting it to zero means that if 
you have line numbers greater than 255 in the original program, they 
will be correctly reset to low numbers. The zero in the accumulator is 
then transferred to the Y register by the TAY command, and the 
accumulator is loaded from address $501. This will be the low-byte 
of the next-line address, and it is stored at address $98. The Y 
register is incremented so that the accumulator can be loaded from 
$592. This gets the high-byte of the next line address, and it is stored 
into address $$9. What we now want to do is to put the next line 
address numbers into the addresses $05 and $6 that we used for 
the start address of the first line. If we can do this, we can then repeat 
all the steps of the loop. 

This is done by a set of load and store operations. The last of these 
will have used a positive or zero number in the accumulator 
(certainly not negative), and we can test this to cause the loop. Once 
again, I could have used JMP, with a complete address, but BPL is 
neater. It means ‘branch if positive or zero’, and it only need be 
followed by a single byte displacement. The reason I prefer to use 
branch commands like this rather than JMP is that branch 
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commands make the program ‘relocatable’. A relocatable program 
can be put anywhere in memory, not just into a certain range of 
addresses. If you assemble a program at address $9609, and it 
contains somewhere a step like JM P $9654, then you are stuck with 
that. If you decide that you want to place the program starting at 
address $7009, then the JMP $9654 step will have to be changed to 
$7954. If you have no jumps to locations within the program (you 
can have jumps to ROM or to zero page if you like), then you can 
shift the bytes of a program anywhere in memory and still expect it 
to work. That’s a great advantage, especially if you are using POKE 
Statements to load your machine code. 

Getting back to business, then. You run the BASIC program of 
Fig. 9.8(b) which puts the bytes in place. There’s no CALL, because 
you might not want to renumber this program. You then load inthe 
program that you want to renumber. You poke into address $97 the 
starting line number, usually | or 19. If you forget, the first line 
number will be 9. Then use CALL $9699, and your program will be 
renumbered in steps of | — instantly! 


The way ahead 


No program is ever complete, it’s just a stepping stone to the next 
one. The renumber routine is a good example of a simple beginning 
that can be the foundation for something a lot larger. To start with, 
we could fairly easily make use of the high-byte of the line number, 
so that when the low-byte of the line number exceeded 255, the high- 
byte was incremented. We will have to keep a starting value of high- 
byte in zero page memory, just as we keep the low-byte. Adding this 
allows you to use a much greater range of line numbers, and to 
number in tens if you like. The program at this stage, however, is 
getting to a length which makes you want to use anassembler. Life is 
too short to work on machine code programs of this length with 
POKE methods. Apart from anything else, it’s too wearing to alter 
all the DATA lines each time you think of something new to add. 

Rewriting the GOTO and GOSUB lines is something quite 
different, and though it’s well beyond the scope of this book, it’s as 
well to see why. It’s not difficult to understand how your program 
can be adapted to look through a line, and jump to a subroutine 
when it finds a GOTO, GOSUB or THEN. Each of these is 
represented by a token, and you only have to add a bit of indirect 
addressing, and a few CMP steps to get this far. The trouble starts 
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after this. When you have, in BASIC, a line which ends with GOTO 
1200, for example, the 126 causes problems. This number is stored 
as four ASCII codes, not as a two-byte code. The ROM of the 
Oric/ Atmos must contain a routine which will read a set of ASCII 
codes for numbers, and convert into two-byte form, but you have to 
be sure that you read the correct number of codes, with no letter 
codes. Having got this number you then have to find the address of 
the line that it refers to. This line may not yet have been renumbered, 
so you have to store the address of the GOTO line, and the address at 
which the line number is placed. When the line is renumbered, its 
number has to be converted back to ASCII codes, and these codes 
placed into the correct part of memory. It’s not easy — particularly 
when you consider that a GOTOI5 might become a GOTOI569, 
requiring more memory space, and that there might be thirty of 
them in a program. 

We have come to the end of this particular road now. You now 
know how to write a machine code program, how to place it in 
memory, and how to run it. What you need now, more than 
anything else, is experience. You need to study every machine code 
program that you can lay your hands on. Some of them may not be 
very useful. There are, forexample, a number of programs that work 
on the Oric-1 which will not work on the Atmos because of changes 
in the ROM. Nevertheless, any machine code program for the 6502 
microprocessor will have something of interest for you. The 6502 is 
used in the BBC Micro and in the Commodore 64, and a lot of 
machine code programs are printed for these two machines. Once 
you can see what a machine code program is trying to do, you can 
adapt it for the Oric-1 or the Atmos. For the rest, it’s learning 
addresses and routines all the time. Keep in touch with your user 
group, magazines such as Oric Owner and Oric Computing, and the 
information that you need will flow in your direction. 


Appendix A 


How Numbers are 
Stored 


The Oric/ Atmos uses five bytes of memory to store any number. This 
Appendix describes how numbers are stored, but if you have no 
head for mathematics, you may not be any the wiser! 

To start with, floating point (not integer) numbers are stored in 
mantissa-exponent form. This is a form that is also used for denary 
numbers. For example, we can write the number 216909 as 2.16 X 
105, or the number .$@(12 as 1.2 X 10-4. When this form of writing 
numbers is used, the power (of ten in this case) is called the 
exponent, and the multiplier (a number greater than #) and less than 
1) is called the mantissa. Binary numbers can also be written in this 
way, but with some differences. To start with, the mantissa of a 
binary number that is written in this form is always fractional, but 
no point is written. Secondly, the exponent is a power of two rather 
than a power of ten. We could therefore write the binary number 
19119900 as 1911E1909. This means a mantissa of 111 (imagine it 
as .1911) and exponent of 1999 (2 to the power 8 in denary). There's 
no advantage in writing small numbers in this way, but for large 
numbers, it’s a considerable advantage. The number: 


LIPID 1PPP PPP DP ONO D ANOS 


for example can be written as 119 191E11009 (think of itas 119191 
X 224), 

This scheme is adapted for the Oric/ Atmos, and other machines 
which use Microsoft BASIC. Since the most significant digit of the 
mantissa (the fractional part of the number) is always | when a 
number is converted to this form, it is converted to a @ for storage 
purposes. The exponent then has (denary) 128 added to it before 
being stored. This allows numbers with negative exponents up to 
—128 to be stored without complications, since a negative exponent 
is then stored as a number whose value is less than 128 denary. The 
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Oric/ Atmos uses four bytes to store the mantissa of a number, and 
one byte to store the exponent. 

To take a simple example, consider how the number 29 (denary) 
would be coded. This converts to binary as 1616, which is 
19199900 X 25, writing it with the binary point shown, using eight 
bits, and with the exponent in denary form. The msb of the fraction 
is then changed to 9, so that the number stored is 09199909. 
Peeking this memory will therefore produce the number (denary) 32 
in the mantissa lowest byte. Meantime, the exponent of 5 is in binary 
161. Denary 128 is added to this, to make 19999101. Peeking this 
memory will give you 133 (which is 128+5). 

Integers need only two bytes for storage. The integer must have a 
value between —32768 and +32767. To convert an integer to the 
form in which the Oric/ Atmos stores it, proceed as follows: 


1. If the number is negative, subtract it from 65536 and use the 
result. 

2. Divide the number by 256 and take the whole part. This is the 
most significant byte. 

3. Subtract from the number 256 X (most significant byte). This 
gives the least significant byte. 


Example: Convert 9438 into integer storage form. 
The number is positive, so it can be used directly. 
9438 /256=36.867 187. 

The msb is therefore 36. 
36*256=9216, and 9438-9216=222. 
The low byte is 222. 


Appendix B 
Hex and Denary 
Conversions 


(a) Hex to Denary 


For single bytes (two hex digits) - 
Multiply the most significant digit by 16, and add the other digit. 
For example: 


$3D is 3*16 + 13 =61 denary. 


For double bytes (address numbers) - 

Write down the least significant digit. Now write under it the value 
of the next digit, multiplied by 16. Under that, write the next digit, 
multiplied by 256. Under that, write the next digit, multiplied by 
4996. 

For example: 


$F3DB converts as follows: 


Write Is digit 1] 
Next digit*16 is 13*16 208 
Next digit*256 is 3*256 768 


Next digit*4996 is 15*4996 61449 
Now take the total, which is 62427 


Denary to hex 


For single bytes (less than 256 denary) - oe 
Divide by 16. The whole part of the number is the most significant 
digit. The least significant digit is the fractional part of the result 
multiplied by 16. 


a tr nr 


es Reena seen eeeanes 
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For example: 
To convert 155 to hex: 
153/16 = 9.6875, so 9 is the most significant digit. 
The least significant digit is .6875* 16, which is 11. This converts 
to hex B, so that the number is $9B. 


For double-byte numbers (numbers between 256 and 65535 denary) 
Divide by 16 as before. Note the whole number part of the result, 
and write down the fractional part, times 16, as a hex digit. Repeat 
the action with the whole number part, until only a single hex digit 
remains. 

For example: 


To convert 23815 to hex: 

23815/ 16=1488.4375. The fraction .4375* 16 gives 7, and this is 
the least significant digit. 

Taking the whole number part, 1488/ 16=93.09. Since there is 
no fraction, the next hex digit is 9. 

93/16=5.8125. The fraction .8125, multiplied by 16 gives 13, 
which is hex D. This is the third hex figure. Since the whole 
number part is less than 16 (it’s 5), then this is the most 
significant digit, and the whole number is $5DQ7. 


Appendix C 
The Instruction Set 


The instruction set of the 6502 isa relatively small one, but there will 
be some instructions in this list which you may never need to use 
unless you go in for very advanced programming indeed. A full 
description of the action of each instruction would take too much 
space, and so the action has been indicated by abbreviations. Fora 
full description, see one of the books devoted to 6502 programming. 
In general, M means a byte at an address in memory, and the 
registers are referred to under their usual letter references. An arrow 
indicates where the result of an action is stored. For example, 
A+M-+C-—A+C means that the byte in the memory (addressed by 
the instruction) is added to the byte in the accumulator A, plus the 
carry C, and the result is placed in the accumulator A, with another 
possible carry in C. 

The instruction codes are shown in columns graded by the 
addressing method. These methods are Immediate, Zero Page, Zero 
Page X Indexed, Absolute, Absolute X Indexed, Absolute Y 
Indexed, Indirect X, Indirect Y,and PC Relative. A few instructions 
use Implied Addressing. The implied addressing method means that 
no special addressing is needed. In the assembly language forms, 
ADDR means a full two-byte address and addr means a single 
(lower) byte address for zero page addressing. Disp is used to mean 
displacement in PC Relative addressing. Byte means the byte 
following an immediate addresses code. S has been used to mean the 
Processor Status register. Flags are referred to as C,N and V. All 
Op codes are shown in hex. 
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Assembly language form Addressing method Opcode Action 


ADC # Byte Immediate 69 A+M+C—-A+C 
ADC addr Zero page 65 

ADC addr, X Zero page, X bs 

ADC ADDR Absolute 6D 

ADC ADDR,X Absolute, X 7D 

ADC ADDR, Y Absolute, Y 79 

ADC (addr, X) Indirect, X 6l 

ADC (addr), Y Indirect, Y 71 

AND # Byte Immediate 29 A AND M--A 
AND addr Zero page 25 

AND addr, X Zero page, X 35 

AND ADDR Absolute 2D 

AND ADDR,X Absolute, X 3D 

AND ADDR, Y Absolute, Y 39 

AND (addr, X) Indirect, X 21 

AND (addr), Y Indirect, Y 31 

ASLA Implied PA Shift left 

ASL addr Zero page 06 

ASL addr, X Zero page, X 16 

ASL ADDR Absolute OE 

ASL ADDR, X Absolute, X LE 

BCC Disp Relative 96 Branch if C=@ 
BCS Disp Relative BO Branch if C=1 
BEQ Disp Relative FO Branch if Z=I 
BIT addr Zero page 24 OR with M, 
BIT ADDR Absolute 2C Test N & V 
BMI Disp Relative 30 Branch if N=1 
BNE Disp Relative Dé Branch if Z=@ 
BPL Disp Relative 19 Branch if N=9 
BRK Implied my) Interrupt program 
BVC Disp Relative 50 Branch if V=@ 
BVS Disp Relative 79 Branch if V=1 
CLC Implied 18 Clear carry 


CLD Implied D8 Clear decimal mode 
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Assembly language form Addressing method Opcode Action 





CLI 
CLV 


CMP #Byte 
CMP addr 
CMP addr, X 
CMP ADDR 


CMP ADDR, X 


CMP ADDR, Y 
CMP (addr, X) 
CMP (addr), Y 


CPX # Byte 
CPX addr 
CPX ADDR 


CPY # Byte 
CPY addr 
CPY ADDR 


DEC addr 
DEC addr, X 
DEC ADDR 


DEC ADDR, X 


DEX 
DEY 


EOR # Byte 
EOR addr 
EOR addr, X 
EOR ADDR 


EOR ADDR, X 
EOR ADDR, Y 


EOR (addr, X) 
EOR (addr), Y 


INC addr 

INC addr, X 
INC ADDR 
INC ADDR, X 


INX 
INY 


Implied 
Implied 


Immediate 
Zero page 
Zero page, X 
Absolute 
Absolute, X 
Absolute, Y 
Indirect, X 
Indirect, Y 


Immediate 
Zero page 
Absolute 


Immediate 
Zero page 
Absolute 


Zero page 
Zero page, X 
Absolute 
Absolute, X 


Implied 
Implied 


Immediate 
Zero page 
Zero page, X 
Absolute 
Absolute, X 
Absolute, Y 
Indirect, X 
Indirect, Y 


Zero page 
Zero page, X 
Absolute 
Absolute, X 
Implied 


Implied 


58 
B8 


Clear interrupt disable 
Clear V flag 
A-M, set flags 


X-M set flags 


Y-M set flags 


M-I-M 


X-1-X 
¥-Il-¥ 
A EOR M>A 


M+I-M 


X+1-X 
¥t1-7 
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Assembly language form Addressing method Opcode Action 


JMP ADDR 
JMP (ADDR) 


JSR ADDR 


LDA # Byte 
LDA addr 

LDA addr, X 
LDA ADDR 
LDA ADDR, X 
LDA ADDR, Y 
LDA (ADDR, X) 
LDA (ADDR), Y 


LDX # Byte 
LDX addr 
LDX addr, Y 
LDX ADDR 
LDX ADDR, Y 


LDY # Byte 
LDY addr 

LDY addr, X 
LDY ADDR 
LDY ADDR, X 


LSRA 

LSR addr 

LSR addr, X 
LSR ADDR 
LSR ADDR, X 


NOP 


ORA # Byte 
ORA addr 
ORA addr, X 
ORA ADDR 
ORA ADDR, X 
ORA ADDR, Y 
ORA (addr, X) 
ORA (addr), Y 


PHA 


Absolute 
Indirect 


Absolute 


Immediate 
Zero page 
Zero page, X 
Absolute 
Absolute, X 
Absolute, Y 
Indirect, X 
Indirect, Y 


Immediate 
Zero page 
Zero page, Y 
Absolute 
Absolute, Y 


Immediate 
Zero page 
Zero page, X 
Absolute 
Absolute, X 


Implied 
Zero page 
Zero page, X 
Absolute 
Absolute, X 


Implied 


Immediate 
Zero page 
Zero page, X 
Absolute 
Absolute, X 
Absolute, Y 
Indirect, X 
Indirect, Y 


Implied 


4C 
6C 


Jump to ADDR 
Jump to stored 
address 


Jump to subroutine 


M-A 


M~-X 


Shift right 


No operation 


AOR M-A 


Push A on stack 
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Assembly language form Addressing method Opcode Action 





PHP 


PLA 
PLP 


ROLA 

ROL addr 
ROL addr, X 
ROL ADDR 


ROL ADDR, X 


RORA 
ROR addr 


ROR addr, X 
ROR ADDR 
ROR ADDR, X 


RTI 
RTS 


SBC # Byte 
SBC addr 
SBC addr, X 
SBC ADDR 


SBC ADDR, X 
SBC ADDR. Y 
SBC (addr, X) 
SBC (addr), Y 


SEC 

SED 

SEI 

STA addr 


STA addr, X 
STA ADDR 


STA ADDR, X 
STA ADDR, Y 
STA (addr, X) 
STA (addr), Y 


STX addr 
STX addr, Y 
STX ADDR 


Implied 
Implied 
Implied 


Implied 
Zero page 
Zero page, X 
Absolute 
Absolute, X 


Implied 
Zero page 
Zero page, X 
Absolute 
Absolute, X 


Implied 
Implied 


Immediate 
Zero page 
Zero page, X 
Absolute 
Absolute, X 
Absolute, Y 
Indirect, X 
Indirect. Y 


Implied 
Implied 
Implied 


Zero page 
Zero page, X 
Absolute 
Absolute, X 
Absolute, Y 
Indirect, X 
Indirect. Y 


Zero page 


Zero page. Y 
Absolute 


8 


E9 
ES 
F5 
ED 
FD 
F9 
El 
Fl 


38 
F8 
78 


85 
95 
8D 
9D 
99 
81 
9] 


86 
96 
8E 


Push S on stack 


Pull A from stack 
Pull S from stack 


Rotate left 


Rotate right 


Return from interrupt 


Return from sub- 
Routine 


A-M-C*#—M 
C* isa borrow 


Set carry flag 
Set decimal mode 
Set interruptdisable 


A-M 
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Assembly language form Addressing method Opcode Action 





STY addr 
STY addr, X 
STY ADDR 


TAX 
TAY 
TYA 
TSX 

TXA 
TXS 


Zero page 
Zero page, X 
Absolute 


Implied 
Implied 
Implied 
Implied 
Implied 
Implied 


84 
94 
8C 


AA 
A8 
98 
BA 
8A 
9A 


Y-M 


A-X 
A-Y 
AA 
SX 

X-A 
X-S 





Appendix D 
Addressing Methods of 
the 6502 


Each addressing method has the effect of using a byte in the 
memory. The address at which this byte is stored is called the 
Effective Address (EA). The purpose of any addressing method is to 
make use of an effective address. 


Immediate Addressing: The EA is the address that immediately 
follows the instruction byte. 


Zero Page Addressing: Only the lower byte of the EA is given in the 
instruction. The upper byte is always $9, hence the name of zero 
page. For example, using zero page addressing with a byte of FB 
would make use of the address $0@ FB. 


Absolute Addressing: The instruction is followed by two bytes, 
which form a complete address. For example, LDA $563F means 
that the accumulator is to be loaded from the address $563F. 


Indexed Addressing: A number is stored in one of the index 
registers (X or Y). The effective address is this number plus any 
address that is specified in the instruction. For example, LDA 25, X 
means load the accumulator from the address which consists of the 
number stored in the X register, plus 25. 


Implied Addressing: The address is implied by the instruction, and 
no special address reference is needed. For example, INX means 
increment the X register, and no EA is needed. 


Indirect Addressing: There are two forms, both of which use zero 
page addresses. The X-indexed indirect adds the contents of the X 
register to the zero page address number, and fetches the byte at 
this address. This forms the low byte of the effective address. The 
high byte is then fetched from the next higher page zero address. The 
Y-indexed indirect fetches the byte from the page zero address, and 
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then adds the contents of the Y register to this byte. This is the lower 
byte of the effective address, and the higher byte is fetched from the 
next zero page address as before. 


Appendix E 
Passing Parameters 


Since this book has been intended as a gentle introduction, I have 
tried as far as possible to duck under some of the more difficult 
problems that can arise when you want to program in machine code. 
One of these problems is that of ‘passing parameters’, and it’s 
particularly important when you use a combination of BASIC and 
machine code for programming, as many programmers do. 

First of all, what is meant by ‘passing parameters’? A parameter is 
a quantity that has a value which may be fixed for a time but which 
can also be altered. In BASIC, we often use variables as parameters, 
meaning that they take values for a short time only. When you 
program a loop that starts FOR N=! TOS, forexample, the value of 
X will be | on the first pass through the loop, 2 in the next pass, and 
so on. Between the FOR line and the NEXT line, the value of X is 
fixed - it doesn’t change until the loop is completed. That’s what we 
mean by a parameter keeping its value for a time. 

When you get into more advanced programming, you will often 
encounter the problem of ‘passing parameters’. This usually means 
making use of a parameter in more than one routine. For example, 
suppose you had a BASIC program which in line 199) had a 
subroutine for printing text centred on the screen. In this 
subroutine, the text might be represented by a variable name of TXS. 
Now if you happen to have a title which is assigned to the name of 
TX$, you can print it centred by having the instruction 
GOSUBI199@ in your program. What do you do if your heading 
happens to use the variable name of NM$? Simple, in BASIC, you 
just use the line: 


TXS=NMS:GOSUBIQ99 


The TX$=NMS$ part passes the value of parameter NM$ to the 
name TX$, and this is what passing parameters, at its simplest, is 
about 
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This book is about machine-code programming, however, and the 
problem that is likely to haunt us is how to pass parameters to a 
machine code program from a BASIC program. As you might 
expect, there is more than one possible method, and the simplest is 
to use memory as what is called a ‘parameter block’. A parameter 
block is a set of numbers stored in consecutive addresses in memory, 
which the machine code program can make use of. The parameter 
block can be filled by poking numbers from a BASIC program, or 
by storing them from another machine-code program. It’s even 
possible to have one program store numbers which another program 
will use later. 

Take a simple example. Suppose you have a BASIC program that 
requires you to inputa title. The machine code program will animate 
this title, making the letters appear to fly all over the screen. We’re 
not going to look at the whole program, just the problem of 
parameter passing. What has to be passed is a set of ASCII codes, 
the codes for the letters of the message. We can use a pair of lines 
like: 

599 AD=388909:FOR N=I TO LEN(A$) 
519 POKE AD+N,ASC(MIDS(AS,N,1)): NEXT 


which will place the ASCII codes into memory starting at address 
3889 1. This is our parameter block, and you have to ensure that you 
have some method of reading the correct number of bytes when the 
machine-code runs. You could, for example, have a terminator after 
the last ASCII code, or you could place the count number, LEN(A$) 
into another memory address (perhaps 3880) so that the machine- 
code program could read it. 

A parameter block is a useful way of passing quite a large amount 
of information from a BASIC program to machine code, and it can 
also be used to pass information in the other direction. When a 
single number has to be passed, however, there is a rather more 
convenient method, which makes use of the USR command. Just as 
you have to specify the address of a machine code routine to use with 
CALL, you also need to specify an address with USR. This is done 
by a line in your BASIC program which reads: 


199 DEFUSR=38409 


— using whatever address number you have allocated for the start of 
your machine code. The difference between this and CALL38499, 
however, is that when this line is run, the machine code program isn’t 
called! All that happens is that the address is stored in memory ready 
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for a call. To call the machine code into action, you must use a line 
like: 


PRINT USR(24.5) or A = USR(4237) 


The number within the brackets is the parameter which will be 
passed to the machine code program, and it could be a variable 
name, as in A=USR(X). 

The next thing to look at is what happens to this number. It is 
stored in what Oric call the ‘floating-point accumulator’. This is a 
parameter block in the memory, which takes addresses $D@ to $D5. 
To understand how numbers are stored here, you will have to 
grapple with Appendix A again. The format is slightly different. 
Address $D@ is used to store the exponent of the number (in binary 
fraction form), after adding 128 to the value. The next four bytes, 
from $D1 to$D4 are used to store the mantissa. Address $DS is used 
to store a sign byte, with § meaning positive and $FF meaning 
negative. If the number is zero, the exponent byte is zero. Your 
machine code program must be arranged so that it can work with the 
numbers that are stored in this way. 

When the machine code has run, then the result of any work on 
the number is also placed in the ‘floating-point accumulator’, and is 
passed back to BASIC. If you called the machine code by using: 


PRINT USR(24.5) 


for example, then the resu/t of the machine code calculation will be 
printed. If you used A=USR(12345), then A contains the result. For 
many applications of machine code that do not involve the use of 
floating-point numbers, CALL is a much easier method of running 
machine code, free from the complications of USR. When you are 
able to write machine code programs that make use of floating-point 
numbers, the complications of USR will be much less formidable! 


Appendix F 
A CTRL Z Reset Action 


The Oric-! and Atmos both use a RESET system which requires a 
button underneath the computer to be pressed. This button is not 
very accessible, and in my book on the Oric-1, I suggested gluing on 
a plastic extension button, using ‘superglue’. An alternative is to 
have a ‘soft-action’ reset. This is a program which can be loaded in 
when you first switch on, and which will then allow you to carry out 
the RESET action by pressing ordinary keys. You can make the 
program recording in machine code, autorunning, so that it is quick 
and easy to use. I have tested this only on the Atmos, however. 

The principle is that you can reset the Atmos machine by calling 
the address $F8B2 — the Oric-! will require a different address, 
possibly $F 430. The cunning part is to make this happen when a set 
of keys is depressed. As it happens, using the CTRL key along witha 
letter key will generate a unique code, and the code that is generated 
when CTRL and Z are pressed at the same time is $1A. If we 
interrupt the normal keyboard routine with a little piece of code that 
checks for $1A in the accumulator, we can carry out the ‘soft reset’. 
If $1A is present, the program will jump to the reset address. If this 
byte is not present, the program returns to normal by jumping to 
$EB78 (Atmos). 


1@ A=#4e0 
2@ FORN=@T020:READ D¢$ 

SQ POKEA+4N, VAL ("#"+D%) : NEXT 

4@ CALLA 

1@@ DATAAS, B, SD, 3C, 2,A9,4, 8D, SD, 2, 40, 
C9, 1A, DO, 5, 24, B2,F8, 4C,78,ER 


Fig. F.1 
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Since you are by now no longer a novice machine code 
programmer, I'll simply show the BASIC POKE program (Fig. F!) 
for this routine, and leave you to work out what has been done, now 
that you know the principles. The program has been assembled in 
the memory at $9499. 
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Sooner or later most users feel the need to use machine 
code to achieve higher speeds, more spectacular effects 
and better control. This book is an essential introduction 
to machine code for Oric and Atmos owners who take 
their computing seriously and want to get higher 
performance from their machine. 


Many illustrative programs are included to help you get 
started, and everything is set out in a practical way with 
explanations that are easy to understand. You will gain 
valuable insight into the working of the machine, and the 
book gives the most useful entry points and memory 
locations. Soon you will be amazing yourself with your 
own versatility! 
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